I've encountered a scenario where git rebase --interactive drops a
commit which contains a modification to a submodule but no other changes.
This occurs when there is a conflict when applying the commit (for
example if the submodule's history has been rewritten and you are
rewriting the parent repository to match the new version of the submodule).
To clarify:
git rebase -i
# Edit a commit, switching submodule to an unrelated commit
git rebase --continue
# Conflict in submodule, checkout the correct submodule commit
git add path/to/submodule
# Only change in index is updated submodule
git rebase --continue
# No commit is created for the submodule change
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.
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.
--
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