git is giving me a major headache when using --fixup and --autosquash. I would like to give two examples, one working perfectly fine and the other being a mess. (git version 2.6.2)
Working example:
First commit:
$ git init
$ printf '1\n' > test.file
$ git add test.file
$ git commit -m 'Insert 1 --> first line'
$ cat test.file
1
Second commit (BUG):
$ printf 'This is\na BUG\n' >> test.file
$ git commit -am 'Added line 2 and 3 with BUG'
$ cat test.file
1
This is
a BUG
Third commit:
$ sed -i '2i 2' test.file
$ git commit -am 'Insert 2 --> second line'
$ cat test.file
1
2
This is
a BUG
Fourth commit (fixup):
$ sed -i 's/a BUG/NOT a BUG/' test.file
$ git add test.file
$ git log --oneline
b021696 Insert 2 --> second line
2e18b8d Added line 2 and 3 with BUG
d7b60a1 Insert 1 --> first line
$ git commit --fixup HEAD~
$ cat test.file
1
2
This is
NOT a BUG
Rebase:
$ git log --oneline
fe99989 fixup! Added line 2 and 3 with BUG
b021696 Insert 2 --> second line
2e18b8d Added line 2 and 3 with BUG
d7b60a1 Insert 1 --> first line
$ git rebase -i --autosquash HEAD~3
[detached HEAD 6660b0e] Added line 2 and 3 with BUG
Date: Tue Nov 3 13:28:07 2015 +0100
1 file changed, 2 insertions(+)
Successfully rebased and updated refs/heads/master.
Headache example: (Only difference is the BUGGY commit is a single line)
First commit:
$ git init
$ printf '1\n' > test.file
$ git add test.file
$ git commit -m 'Insert 1 --> first line'
$ cat test.file
1
Second commit (BUG):
$ printf 'This is a BUG\n' >> test.file
$ git commit -am 'Added line 2 with BUG'
$ cat test.file
1
This is a BUG
Third commit:
$ sed -i '2i 2' test.file
$ git commit -am 'Insert 2 --> second line'
$ cat test.file
1
2
This is a BUG
Fourth commit (fixup):
$ sed -i 's/a BUG/NOT a BUG/' test.file
$ git add test.file
$ git log --oneline
2b83fe7 Insert 2 --> second line
62cdd05 Added line 2 with BUG
0ee3343 Insert 1 --> first line
$ git commit --fixup HEAD~
$ cat test.file
1
2
This is NOT a BUG
Rebase:
$ git log --oneline
c3d3db7 fixup! Added line 2 with BUG
2b83fe7 Insert 2 --> second line
62cdd05 Added line 2 with BUG
0ee3343 Insert 1 --> first line
$ git rebase -i --autosquash HEAD~3
error: could not apply c3d3db7... fixup! Added line 2 with BUG
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply c3d3db78440e48c1bb637f78e0767520db65ea1e... fixup! Added line 2 with BUG
$ git status
interactive rebase in progress; onto 0ee3343
Last commands done (2 commands done):
pick 62cdd05 Added line 2 with BUG
fixup c3d3db7 fixup! Added line 2 with BUG
Next command to do (1 remaining command):
pick 2b83fe7 Insert 2 --> second line
(use "git rebase --edit-todo" to view and edit)
You are currently rebasing branch 'master' on '0ee3343'.
(fix conflicts and then run "git rebase --continue")
(use "git rebase --skip" to skip this patch)
(use "git rebase --abort" to check out the original branch)
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: test.file
no changes added to commit (use "git add" and/or "git commit -a")
$ cat test.file
1
<<<<<<< HEAD
This is a BUG
=======
2
This is NOT a BUG
>>>>>>> c3d3db7... fixup! Added line 2 with BUG
Why does the fixup not apply cleanly?
Why does the fixup also contain "2" which should not be in the patch introduced by the fixup but in the patch of the former commit.
I think that the problem is the context of the changes. Look at this commit:
And you want to apply this patch to the file with contents:
See? The patch does not apply, because the context does not match. So a conflict arises and you have to fix it manually.
When you have the bugger line split in two, the patch is something like:
And the file is:
Now, while the match is not perfect, at least the first unmodified line of the context matches, so the merge may continue.
When you do a
--fixup
, you are applying a patch out of order, so the context has disappeared. In the first case, your patches are applied as follows:1
on line 1This is\naBUG
on lines 2, 3 after1
a BUG
, on line 4, afterThis is
, replace withNOT a BUG
2
on line 2 after1
, beforeThis is
Steps 2, 3 are pretty clear-cut. Even though the line number is different than expected in step 3, the context makes it clear. In the second case,
1
on line 1This is a BUG
on line 2 after1
This is a BUG
, replace withThis is NOT a BUG
on line 3 after line2
2
on line 2, after1
, beforeThis is a BUG
In this case, patch #3 is impossible because
This is a BUG
does not appear on line 3 and the line before it is not2
. Git does not assume that line 2 is the correct one in this case because of the missing context.The easiest way to fix this problem is to rearrange the order of the rebase to reflect what you are actually doing. Instead of the original order:
switch the last two elements to give the patch the context it needs:
In this case, you may need to add the
-k
flag to your command line to preserve the last commit, which is basically empty:The other alternative is of course to fix the conflict manually using
git merge
orgit mergetool
, following the prompts when the rebase fails.You can make the rebase "succeed" by adding
-s recursive -X theirs
or-s recursive -X ours
to specify the strategy. However, because of the context conflict, your fixup will get clobbered in both of those cases.Beware there is another case, when using
git rebase --autosquash
, of headache.Git 2.20 (Q4 2018) just fixed a bug related to autosquash: "
git rebase -i"
did not clear the state files correctly when a run of "squash/fixup" is aborted and then the user manually amended the commit instead, which has been corrected.See commit 10d2f35, commit 2f3eb68 (31 Aug 2018) by Johannes Schindelin (
dscho
). (Merged by Junio C Hamano --gitster
-- in commit 87ae8a1, 24 Sep 2018)