git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Cch <cr@onlinehome.de>
Date
Jun 11, 2018, 16:06 UTC
Message-ID
<8e28202a-8646-53e8-8c22-389d61791c70@onlinehome.de>
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
Next: Jeff King
Message 1 of 19 in “[BUG] git-rebase: reword squashes commits in case of merge-conflicts”
  1. chJun 11, 2018
  2. Jeff KingJun 12, 2018
  3. chJun 15, 2018
  4. Elijah NewrenJun 16, 2018
  5. Eric SunshineJun 17, 2018
  6. sequencer: do not squash 'reword' commits when we hit conflictsElijah Newren, Jun 17, 2018
  7. Phillip WoodJun 17, 2018
  8. Johannes SchindelinJun 17, 2018
  9. Phillip WoodJun 18, 2018
  10. Junio C HamanoJun 18, 2018
  11. Johannes SchindelinJun 18, 2018
  12. Phillip WoodJun 19, 2018
  13. sequencer: do not squash 'reword' commits when we hit conflictsPhillip Wood, Jun 19, 2018
  14. Elijah NewrenJun 19, 2018
  15. Junio C HamanoJun 19, 2018
  16. t/lib-rebase.sh: support explicit 'pick' commands in 'fake_editor.sh'SZEDER Gábor, Aug 23, 2018
  17. Junio C HamanoAug 23, 2018
  18. Johannes SchindelinAug 23, 2018
  19. Johannes SchindelinJun 17, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.