在过去几次,我们遇到了一个问题,即开发人员(明确地或有效地)完成了git merge -s ours
他们不应该做的事情,提交已经丢失而我们只有在清理更加复杂和耗时时才会检测到这一点。测试没有失败,因为添加测试的提交被静默地还原了他们正在测试的代码。
我想要做的是找到或创建一个总结合并的工具,通过正常的合并生成类似下面的输出:
Lines Left(2b3c4d) Right(3c4d5e)
Common with base 970 930
Unique wrt base 20 50
Unique wrt other 15 45
Unique wrt merge 15 45
Common with merge 995 985
但是,如果合并不正确,还原了许多更改,或者执行了git merge -s ours
,则可能会生成如下报告:
Lines Left(2b3c4d) Right(3c4d5e)
Common with base 970 930
Unique wrt base 20 50
Unique wrt other 15 45
Unique wrt merge 15 0 !!
Common with merge 990 935
Warning: 100% of changes from 3c4d5e are missing from merge commit!
如果这个报告是为每次提交运行的,那么只要合并在臭方面,我们就可以标记(通过jenkins作业)。
到目前为止,我一直在玩git diff --stat
,git diff --name-status
和git diff --summary
,但到目前为止,没有人能够满足我的需求。
到目前为止,我能做的最好的事情会产生类似于以下内容的正常合并:
base..left base..right left..merge right..merge
f67c4..a9eb4 f67c4..5b592 a9eb4..cb209 5b592..cb209
a | 1 + 1 +
b | 1 + 1 +
base | 1 + 1 + 1 + 1 +
changed 2 2 2 2
insertions(+) 2 2 2 2
deletions(-) 0 0 0 0
和ours
合并:
base..left base..right left..merge right..merge
f67c4..a9eb4 f67c4..5b592 a9eb4..95637 5b592..95637
a | 1 + 1 -
b | 1 + 1 +
base | 1 + 1 + 2 +-
changed 2 2 0 3
insertions(+) 2 2 0 2
deletions(-) 0 0 0 2
请注意,我不仅想要检测-s ours
合并,我还想了解一些但不是所有更改都在合并中的情况。这是检测错误合并的一般情况,而不仅仅是检查丢失更改的一个特定原因。
此外,这似乎只在合并中存在冲突时发生,因此任何需要自动再次运行合并的方法也需要自动解决这些冲突。
最后,我希望能够在脏回购中运行此摘要实用程序,而不首先隐藏我的所有更改,因此我当前使用git diff
进行了实验。
对于如何比具有大量解析和重新格式化的脚本更直接地获取此类信息的任何建议都将不胜感激。
我能找到的最接近的现有问题是:Detect a merge made by '-s ours'(但唯一的答案没有帮助)和“git merge -s ours” and how to show difference(但根本没有答案)。 功能
答案 0 :(得分:1)
我遇到了这个问题,最后编写了一个工具来检测这些类型的合并。虽然我无法共享实际代码(它在技术上由我的雇主拥有),但算法非常简单:让S1成为合并与合并的第二个父级之间发生变化的所有文件的集合。设S2是合并和合并库之间有所变化的所有文件的集合。从S1中减去S2,并留下可能由于合并而丢失更改的文件集。
这不仅会检测使用-s ours
进行的合并,还会检测到第二个父级中的某些但不是全部更改进入合并的混乱。