git 子模块合并冲突:如何可视化?
当我最近发现
git submodule summary
这很好地向我展示了哪个提交时,我非常高兴,子模块的签出提交位于存储库中的引用之前或之后。
现在,当我正在进行子模块冲突合并时,相同的命令不会产生有用的输出。我需要在我的主树中进行一系列痛苦的 gitk 检查分支,以及 cd'ing 到子模块中,在其中获取和 gitk,比较 sha1 值......
什么是更方便的方法来获取冲突的图片?
I was pretty happy when I found out lately about
git submodule summary
which shows me nicely by which commits the checked out commit of a submodule is ahead or behind the reference in the repository.
Now when I am in the middle of a merge with submodule conflicts, the same command does not produce useful output. I need a painful sequence of gitk in my main tree examining the branches, along with cd'ing into the submodules, fetching and gitk in there, comparing sha1 values...
What would be a more convenient way to get the picture of the conflict?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
你可以制作一个脚本。以下是此类脚本的核心:
您可以将 diff 替换为 log 或任意数量的其他命令,以帮助您查看更改内容。一种是看看它是否是快进合并,在这种情况下,您可以快速解决冲突,而无需在子模块级别进行合并。
还有 gitslave 可以帮助您解决此类问题。
希望这有帮助。
You can make a script. Here is the core of such a script:
you can replace diff with log or any number of other commands that will help you see what the changes are. One would be to see if it would be a fast-forward merge in which case you can resolve the conflict quickly without merging at the submodule level.
There is also gitslave which will help you with such issues.
Hope this helps.
与 Adam 的回答相同,但使用索引且不进行剪切:
说明:
当存在冲突时,Git 会存储有关冲突的信息在索引中。它存储了几个不同的版本,即所谓的阶段。第 1 阶段是“基础”版本(共同祖先),第 2 阶段是“我们的”版本,第 3 阶段是“他们的”版本。
如果出现文件冲突,索引将包含不同版本的 blob 对象 ID。对于子模块,它是子模块提交 ID。在上面的命令中,
:2:$sub
指的是路径$sub
处子模块的阶段2
(我们的)。请注意,您可以使用 git ls-files --stage 来查看带有阶段的索引条目列表。
Same as Adam's answer, but using the index and without cut:
Explanation:
When there is a conflict, Git stores information about it in the index. It stores several different versions, so-called stages. Stage 1 is the "base" version (common ancestor), stage 2 is the "ours" version and stage 3 is the "theirs" version.
In case of file conflicts, the index contains the blob object IDs for the different versions. In case of submodules, it's the submodule commit IDs. In the command above,
:2:$sub
refers to stage2
(ours) of the submodule at path$sub
.Note that you can see a list of index entries with stages using
git ls-files --stage
.