Re: Interactive rebase with submodules

From: John Keeping <john@metanate.com>
Date: Jan 18, 2012, 11:21 UTC
Message-ID: <4F16AB2E.30706@metanate.com>
In-Reply-To: <4F15E83D.10509@web.de>

On 17/01/12 21:29, Jens Lehmann wrote:

> Am 17.01.2012 19:47, schrieb John Keeping:
>> This appears to be because the git-rebase--interactive script inspects whether there is anything to commit when `rebase --continue` is invoked by running:
>>
>>      git diff-index --cached --quiet --ignore-submodules HEAD --

Show 8 quoted lines

>> Is there a reason for the `--ignore-submodules` in this command? Removing that option results in the expected behaviour.
>
> Yes, removing it will help your use case but break others. The reason
> for that is that because submodules are not updated during a rebase
> it doesn't make sense to compare their HEAD to what is recorded in
> the superproject, as that might have been changed by an earlier
> commit. And as the submodules HEAD hasn't been updated back then,
> it is stale and will always show up as modified (even if it wasn't).

Is this worse than the current behaviour? If I perform a rebase where there is a (non-submodule) conflict in a commit where a submodule changes I can see something like:

# Changes to be committed: # modified: path/to/submodule # # Unmerged paths: # both modified: path/to/file # # Changes not staged for commit: # modified: path/to/submodule (new commits)

This occurs if a later commit in the rebase will modify the submodule. In this case, `rebase --continue` correctly recreates the commit once I have resolved the conflict in the file, ignoring the unstaged submodule changes.

Show 5 quoted lines

>> 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?

> 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.

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.

-- 
John