【发布时间】:2017-10-31 15:04:56
【问题描述】:
鉴于以下(稍微做作的)情况 - 3 次提交及其提交消息,其中我比我的原始/主节点提前 2 次提交并且想要重新设置:
C1 <-- origin/master
first commit
* Implement the foo
C2
second commit
* Wibble the foo
* This is temporary to workaround the issue with the thingy, and can be removed after Steve applies his fix.
C3 <-- HEAD
third commit
* Add the wotsit
C3 已签出,我这样做:git rebase origin/master,假设有冲突,所以我看到类似:
First, rewinding head to replay your work on top of it...
Applying: second commit
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging foo.txt
CONFLICT (add/add): Merge conflict in foo.txt
error: Failed to merge in the changes.
Patch failed at 0001 C2
The copy of the patch that failed is found in: .git/rebase-apply/patch
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".
此时,git log 将向我显示导致冲突的提交之前的所有提交,直到 C1:
$ git log
commit C1
Author: Me
Date: Thu Oct 26 16:12:53 2017 +0100
first commit
* Implement the foo
commit C0
Author: Someone else
Date: Wed Oct 25 ...
etc...
为了帮助我了解我当前正在查看的提交是哪个提交,我想查看我当前正在变基的提交的完整消息。
在这种情况下,这是提交 C2 的消息,它提醒我我可以安全地 git rebase --skip 这个提交,因为我的更改是一个临时解决方法,无论如何我都想丢弃。
告诉您冲突的消息仅给出消息“第二次提交”的第一行,而不是带有有用项目符号的正文。
这可能吗?我可以看到这可能很奇怪,因为在我处于 rebase 中间的那一刻,提交并不真正存在,但同样消息必须存在于某个地方,因为当我解决冲突并执行 @ 987654331@,将应用原始提交消息。
【问题讨论】:
-
git show C2不会剪吗? -
@kostix - 我认为它可能会,但挑战在于,在 rebase 告诉你存在冲突时,它只会给你提交消息的第一行它正在尝试应用,所以此时您实际上看不到“C2”,您必须走很长的路才能找到它。
-
看来我找到了the answer。看起来有点 hacky(依赖于实现),但总比没有好。哦,this one 更有趣。 (JFTR 我用谷歌搜索了this)。
-
普通(非交互式,无额外标志)
git rebase实际上使用git format-patch将原始提交系列转换为补丁,然后使用git am应用补丁。这使得很难确定哪个补丁失败了。请参阅@kostix 评论中的答案;请注意,.git/rebase-apply/的格式随着时间的推移而演变,因此其中一些取决于 Git 版本。使用交互式 rebase 使 Git 运行git cherry-pick,这使得更容易看到正在挑选的内容,因为现在在CHERRY_PICK_HEAD中。 -
@kostix - 你完全正确 - 谢谢。我会将其标记为指向该答案的重复链接。事实上,
.git/rebase-apply/0001文件实际上包含消息以及补丁。
标签: git