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 --
>
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.
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html