如何在git rebase期间通过散列识别冲突的提交？ [英] How to identify conflicting commits by hash during git rebase?

问题描述

当我使用 git rebase 遇到合并冲突时，我如何根据提交来确定冲突的来源，而不仅仅是文件差异？

我已经知道如何（基本）使用 git mergetool 或 git add 在之前> git rebase --continue ，但是有时文件之间的差异还不够：我想查看提交日志和

我已经阅读过其他一些问题 git log --merge 会显示父提交，如果我使用 git merge 。无论如何，当我遇到冲突并且被告知致命：--merge without MERGE_HEAD？。

我可以识别有问题的提交吗？

解决方案

简答

它说

 修补程序未能以0001提交消息为F 
  

然后运行

  $ head -1 .git / rebase-apply / 0001 
 From ad1c7739c1152502229e3f2ab759ec5323988326 Mon Sep 17 00:00:00 2001 
  

要获得SHA ad1c77 的失败提交，然后使用 git show ad1c77 来查看它。

长答案

让我们从这棵树开始：

  A --- B --- C --- D 
 \ 
 E --- F --- G 
 
 $ git checkout G 
 $ git rebase D 
  

当发生兑换冲突时， p>

• 来自共同祖先（ B ） PLUS 的上游变化（ C-D ） >已批准的更改并已解决冲突（ E'）与


• 下一个补丁提交（ F ）

让我们看看会发生什么：

$ b'b

  1）A --- B --- C --- D --- E'< -  E成功修补并提交成E' 
 2）A --- B --- C --- D --- E'---<  - 无法将F映射到E'
  pre> 
 
 
以下是错误信息： 
 
 
 首先，将头倒转重播你的作品... 
应用：F 
的提交消息使用索引信息重建基础树... 
回退到修补基地和3路合并。 .. 
自动合并1.txt 
 CONFLICT（内容）：在1.txt中合并冲突
在更改中合并失败。 
补丁失败，提交消息为F 
  
首先，您可以看到它是 F ，因为提交信息出现。但是，如果您的提交消息全部看起来像foo，documentation或some fixes，那么这将无济于事，并且您确实希望SHA ID  ad1c77 或者修补程序的内容。
 
 
 
以下是如何找出 F 的真实身份：
 
 
 
在列出rebase冲突时，它会显示如下内容： 
 
 
 修补程序失败在0001提交消息为F 
  
现在查看 .git / rebase-apply / ，您将在其中找到修补程序文件 0001 ：
 < code $ ls .git / rebase-apply 
 0001头名消息原始头符号
 0002 info msg-clean补丁threeway 
 apply-opt保持下一个安静utf8 
 final-commit last rebound 
  
补丁文件包含原始的commit-id 
  $ head -1 .git / rebase-apply / 0001 
从ad1c7739c1152502229e3f2ab759ec5323988326 Mon Sep 17 00:00:00 2001 
  
然后你可以看在那。
 
 
 
必须有一个更简单的方法，但这是有效的。
 
 
 
请注意，修补程序失败可能是由于不同的提交（如果您正在重新绑定到 HEAD 和rebase目标的共同祖先）。找到该提交相当复杂，尽管您可以尝试使用rebase来找到它： 
 
 
  $ git checkout D 
 $ git rebase G 
  
 
When I encounter a merge conflict using git rebase, how can I identify the source of the conflict in terms of commits, rather than just file differences?


I already know how to make (basic) use of git mergetool or git add before git rebase --continue, but sometimes the differences between files just isn't enough: I want to see the commit log and diff of the commit that just failed to be applied to the working tree.

I've read in other questions that git log --merge would show the parent commits if I were using git merge. I tried it anyways when I encountered a conflict and got told fatal: --merge without MERGE_HEAD?.

How can I identify the problematic commit?
解决方案
Short Answer

If it says 
Patch failed at 0001 commit message for F
Then run
$ head -1 .git/rebase-apply/0001
From ad1c7739c1152502229e3f2ab759ec5323988326 Mon Sep 17 00:00:00 2001
To get the SHA ad1c77 of the failing commit, and then use git show ad1c77 to have a look at it.

Long Answer

Let's start with this tree:
A---B---C---D
     \
      E---F---G

$ git checkout G
$ git rebase D
When a rebase conflict occurs, it is a conflict between 


the upstream changes (C--D) from the the common ancestor (B) PLUS the already rebased changes and already resolved conflict (E') versus
the patch of the next commit (F)


Let's see what happens:
1) A---B---C---D---E'          <- E patched and committed successfully as E'
2) A---B---C---D---E'---       <- failed to patch F onto E'
Here's the error message:
First, rewinding head to replay your work on top of it...
Applying: commit message for F
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging 1.txt
CONFLICT (content): Merge conflict in 1.txt
Failed to merge in the changes.
Patch failed at 0001 commit message for F
First, you can see that it was F, because the commit message appears.  However, if your commit messages all look like "foo", "documentation" or "some fixes", then this won't help, and you really want the SHA id ad1c77 or the contents of the patch.

Here's how to find out the real identity of F:

When it lists the rebase conflict, it will say something like:
Patch failed at 0001 commit message for F
Now look in .git/rebase-apply/, where you will find the patch file 0001:
$ ls .git/rebase-apply
0001          head-name     msg           orig-head     sign
0002          info          msg-clean     patch         threeway
apply-opt     keep          next          quiet         utf8
final-commit  last          onto          rebasing
The patch file includes the original commit-id
$ head -1 .git/rebase-apply/0001
From ad1c7739c1152502229e3f2ab759ec5323988326 Mon Sep 17 00:00:00 2001
You can then look at that.

There must be an easier way, but this works.

Note that the fact that the patch failed may be due to a different commit (if you are rebasing onto a common ancestor of HEAD and the rebase target).  Finding that commit is rather more complicated, although you could try doing the rebase in reverse to find it:
$ git checkout D
$ git rebase G


                        
这篇关于如何在git rebase期间通过散列识别冲突的提交？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！