git rebase -i-自动压扁冲突 [英] git rebase -i -autosquash conflict

问题描述

当使用--fixup和--autosquash时，git令我头疼. 我想举两个例子，一个很好，另一个很烂. (git版本2.6.2)

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)

工作示例:

首次提交:

$ git init
$ printf '1\n' > test.file
$ git add test.file
$ git commit -m 'Insert 1 --> first line'  
$ cat test.file
1

第二次提交(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

第三次提交:

$ sed -i '2i 2' test.file
$ git commit -am 'Insert 2 --> second line'
$ cat test.file
1  
2  
This is  
a BUG

第四次提交(修复):

$ 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

变基:

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

---

头痛的例子:(唯一的区别是BUGGY提交是一行)

---

Headache example: (Only difference is the BUGGY commit is a single line)

首次提交:

$ git init
$ printf '1\n' > test.file
$ git add test.file
$ git commit -m 'Insert 1 --> first line'  
$ cat test.file
1

第二次提交(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

第三次提交:

$ sed -i '2i 2' test.file
$ git commit -am 'Insert 2 --> second line'
$ cat test.file
1  
2  
This is a BUG

第四次提交(修复):

$ 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

变基:

$ 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?

为什么修正程序还包含"2"，它不应出现在修正程序引入的补丁程序中，而应包含在先前提交的补丁程序中.

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.

推荐答案

执行--fixup时，由于未按顺序应用补丁，因此上下文已消失.在第一种情况下，补丁的应用如下:

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. 在第1行上插入1
2. 在1
之后的第2、3行上插入This is\naBUG
3. 删除第4行的a BUG行，在This is之后，替换为NOT a BUG
4. 在1之后，This is
之前的第二行中插入2

1. Insert 1 on line 1
2. Insert This is\naBUG on lines 2, 3 after 1
3. Delete line a BUG, on line 4, after This is, replace with NOT a BUG
4. Insert 2 on line 2 after 1, before This is

第2步，第3步非常简单.即使行号与第3步中预期的不同，上下文也清楚了.在第二种情况下，

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. 在第1行上插入1
2. 在1
之后的第2行中插入This is a BUG
3. 删除第This is a BUG行，在第2行之后的第3行替换为This is NOT a BUG
4. 在第2行的1之后，This is a BUG
之前插入2

1. Insert 1 on line 1
2. Insert This is a BUG on line 2 after 1
3. Delete line This is a BUG, replace with This is NOT a BUG on line 3 after line 2
4. Insert 2 on line 2, after 1, before This is a BUG

在这种情况下，补丁3​​是不可能的，因为This is a BUG不会出现在第3行上，而之前的行也不是2.在这种情况下，由于缺少上下文，Git并不认为第2行是正确的.

In this case, patch #3 is impossible because This is a BUG does not appear on line 3 and the line before it is not 2. 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:

pick 5ef0459 Added line 2 with BUG
fixup ed5cd81 fixup! Added line 2 with BUG
pick 20e104e Insert 2 --> second line

切换最后两个元素，为补丁提供所需的上下文:

switch the last two elements to give the patch the context it needs:

pick 5ef0459 Added line 2 with BUG
pick 20e104e Insert 2 --> second line
fixup ed5cd81 fixup! Added line 2 with BUG

在这种情况下，您可能需要在命令行中添加-k标志以保留上一次提交，该提交基本上是空的:

In this case, you may need to add the -k flag to your command line to preserve the last commit, which is basically empty:

$ git rebase -i -k --autosquash HEAD~3
 Date: Tue Nov 3 10:45:40 2015 -0500
 1 file changed, 2 insertions(+), 1 deletion(-)
Successfully rebased and updated refs/heads/master.
$ cat test
1
2
This is NOT a BUG

当然，另一种选择是在重新设置失败时根据提示使用git merge或git mergetool手动解决冲突.

The other alternative is of course to fix the conflict manually using git merge or git mergetool, following the prompts when the rebase fails.

您可以通过添加-s recursive -X theirs或-s recursive -X ours来指定策略，从而使基准成功".但是，由于上下文冲突，在这两种情况下，您的修复都将变得很麻烦.

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.

这篇关于git rebase -i-自动压扁冲突的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！