Re: [BUG] git-rebase: reword squashes commits in case of merge-conflicts

[Jeff King <peff@peff.net>]

On Mon, Jun 11, 2018 at 06:06:11PM +0200, ch wrote:

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

Thanks for a thorough report. I couldn't reproduce it on v2.17.1 on
Linux, which makes me wonder if the issue is related to git-for-windows
somehow. To the best of my knowledge (and a quick scan of "git diff"
results) the code should be the same, though.

I'm cc-ing Johannes, who is both the resident interactive-rebase expert
_and_ the Git for Windows maintainer. Copious quoting below.

-Peff

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