From: John Keeping <john@metanate•com>
To: Jens Lehmann <Jens.Lehmann@web•de>
Cc: git@vger•kernel.org
Subject: Re: Interactive rebase with submodules
Date: Thu, 19 Jan 2012 10:48:37 +0000 [thread overview]
Message-ID: <4F17F505.5030204@metanate.com> (raw)
In-Reply-To: <4F172DBB.4080303@web.de>
On 18/01/12 20:38, Jens Lehmann wrote:
> Am 18.01.2012 12:21, schrieb John Keeping:
>> On 17/01/12 21:29, Jens Lehmann wrote:
>>> Am 17.01.2012 19:47, schrieb John Keeping:
>>>> I can understand not updating submodules while running the rebase, but I expected that having resolved a conflict and added my change to the index it would be applied by `git rebase --continue`, as indeed it is if there happen to be other (non-submodule) changes in the same commit.
>>>
>>> The irony is that you would have to update submodules (or at least
>>> their HEAD and use "--ignore-submodules=dirty") while running rebase
>>> to make that work in all cases ;-)
>>
>> I don't this this is the case, since diff-tree is being invoked with --cached won't it ignore changes in the work tree anyway?
>
> Right, thanks for nudging me with the clue bat ...
>
> I missed the "--cached" option and did not question if the code does
> what the commit message of 6848d58c6 (where the --ignore-submodules
> option was introduced) said:
>
> Ignore dirty submodule states during rebase and stash
>
> When rebasing or stashing, chances are that you do not care about
> dirty submodules, since they are not updated by those actions anyway.
> So ignore the submodules' states.
>
> Note: the submodule states -- as committed in the superproject --
> will still be stashed and rebased, it is _just_ the state of the
> submodule in the working tree which is ignored.
>
> I think this logic misses the case when only submodule changes are left
> in a commit.
Yes, this is precisely the case that doesn't work as I expect.
>>> But just updating the HEAD would be dangerous as you would have to be
>>> very careful to restore the submodules HEAD after the rebase, or the
>>> submodule's work tree will be out of sync.
>>
>> Just updating HEAD in the submodule without touching its work tree doesn't seem like a good idea. I think it will cause a lot more confusion when running `git status` which will show unexpected modified content for the submodule.
>
> Yes, we agree here.
>
>> Since I did not expect rebase to perform a submodule update, I was not surprised to see unstaged submodule changes when rebasing, but I did expect rebase to commit anything I had added to the index.
>
> Right.
>
> I'll have to add some tests for that case, but I doubt I'll manage that
> today. Until I can provide a complete patch, this diff should fix your
> problem (no, I did not test if that change is enough to fix the problem,
> but at least it does not break the test suite ;-):
>
> ---------------8<--------------
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 5812222..4546749 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -672,7 +672,7 @@ rearrange_squash () {
> case "$action" in
> continue)
> # do we have anything to commit?
> - if git diff-index --cached --quiet --ignore-submodules HEAD --
> + if git diff-index --cached --quiet HEAD --
> then
> : Nothing to commit -- skip this
> else
This patch does indeed fix the problem I was seeing.
Thanks,
--
John
prev parent reply other threads:[~2012-01-19 10:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-17 18:47 Interactive rebase with submodules John Keeping
2012-01-17 21:29 ` Jens Lehmann
2012-01-18 11:21 ` John Keeping
2012-01-18 20:38 ` Jens Lehmann
2012-01-19 10:48 ` John Keeping [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F17F505.5030204@metanate.com \
--to=john@metanate$(echo .)com \
--cc=Jens.Lehmann@web$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox