Hi all!
During a recent rebase operation on one of my repositories a number of commits
unexpectedly ended up getting squashed into other commits. After some
experiments it turned out that the 'reword' instruction seems to squash the
referenced commit into the preceding commit if there's a merge-conflict.
Here's a small reproduction recipe to illustrate the behavior:
1. Create a small test repository using the following Bash script:
----
function add_file()
{
echo "$1" > "$2"
git add "$2"
git commit -m "$3"
}
git init .
add_file "test" "file-1" "master"
git checkout -b stuff
add_file "aaa" "file-2" "feature_a"
add_file "bbb" "file-2" "fixup! feature_a"
add_file "ccc" "file-2" "fixup! feature_a"
add_file "ddd" "file-2" "feature_b"
add_file "eee" "file-2" "fixup! feature_b"
add_file "fff" "file-2" "fixup! feature_b"
----
2. Run
$ git rebase --autosquash --interactive --onto master master stuff
to interactively rebase 'stuff' onto 'master'. This should generate the
following todo-stream:
----
pick ... feature_a
fixup ... fixup! feature_a
fixup <hash_1> fixup! feature_a
pick <hash_2> feature_b
fixup ... fixup! feature_b
fixup ... fixup! feature_b
----
3. Remove the fixup line right before the second pick (i.e. 'fixup <hash_1>')
in order to enforce a merge-conflict later when applying commit <hash_2>.
4. Replace the second pick instruction (i.e. 'pick <hash_2>') with a reword.
5. Launch the rebase operation. It should fail at the 'reword <hash_2>'
instruction due to a merge-conflict.
6. Resolve the conflict by taking the remote-side (i.e. 'ddd'), add the
change to the index with git-add and run
$ git rebase --continue
This should spawn the commit message editor and after saving and quitting
the rebase should finish cleanly.
After the rebase the 'stuff' branch only has a single commit even though I'd
expect there to be two according to the instructions that were passed to
git-rebase. It works as expected if there's either no merge-conflict at the
reword or if the conflicting commit is applied as 'pick'.
I'm running git version 2.17.1.windows.2. I also tried native git version 2.7.4
via WSL (running Ubuntu 16.04.4 LTS) and this version does not exhibit this
behavior.
- ch
