如何在合并提交中列出已解决冲突的统计信息? [英] How to list stats of resolved conflicts in a merge commit?

查看:20
本文介绍了如何在合并提交中列出已解决冲突的统计信息?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在合并分支时,可能会发生冲突,我们应该解决该冲突以完成合并.我们如何仅列出合并中已解决冲突的统计信息?

In merging a branch, a conflict may happen which we should resolve to complete the merge. How can we list ONLY the stats of resolved conflicts in merge?

推荐答案

TL;DR answer: 尝试一下.

TL;DR answer: Just try.

分支在 git 中的成本为零,因此只需创建几个 test_merge_sourcetest_merge_destination 分支并开始合并.5 到 10 分钟后,您要么完成,要么由于发生了一些/一些/许多冲突,您还剩下一点/一些/很多,您可以选择完成/放弃合并尝试.

Branches have a zero cost in git so just create a couple of test_merge_source and test_merge_destination branches and start the merge. After 5-10 minutes you are either done or you still have a little/some/much left because a few/some/many conflicts occurred and you can choose to finish/discard the merge attempt.

很抱歉给您一个否定的答案,但您问题的前提存在根本性缺陷,您所要求的内容是不可能的.

I am sorry to provide you with a negative answer, but the premise for your question is fundamentally flawed and what you ask for is impossible.

因为任何计算机算法都不可能确定某事是否存在冲突.是的,有些工具可以自动合并不同的文件,但即使是完美无故障的合并也可能会造成冲突.

Because it is impossible for any computer algorithm to determine if something is a conflict or not. Yes there are tools that will automate merging of different files, but even a perfect and trouble free merge might still constitute a conflict.

该问题与询问版本之间更改多少行的范围相同,这同样是一个无法回答的问题.

The question is in the same span as asking for how many lines that are changed between versions, which is an equally impossible question to answer.

 /* example1.c */
 #include <stdio.h>
-#include <varargs.h>
+#include <stdarg.h>
 ...
 /* In this diff one line is changed */


 /* example2.c */
 #include <stdio.h>
-#include <varargs.h>
+#include <math.h>
 ...
/* In this diff one line is removed and one line added */

如上所示,一行是否更改完全取决于上下文.因此,没有(理智的)版本控制工具会试图告诉你有多少行发生了变化,他们只会说添加/删除了行.

As shown above, if a line is changed or not is entirely context dependent. Therefore no (sane) version control tool will ever try to tell you how many lines have changed, they only say lines added/removed.

现在,您可能会说您对失败的自动合并感兴趣而不是冲突.很公平,但这完全取决于所使用的工具.例如,如果修改了彼此相邻的两行,则 Git 的内部合并处理将失败,而 KDiff3 不会(这是通常是您想要的,但与距离较远的行相比,这种错误的风险更高,因此需要权衡).

Now, you might say that you are interested in failed automatic merges and actually not conflicts. Fair enough, but this is then wholly dependent on the tool used. Git's internal merge handling will for instance fail if two lines next to each other are modified while KDiff3 will not (which is usually what you want but there is a higher risk of this being incorrect than for lines further apart, so there is a trade off).

这意味着自动合并的内容不是静态的,可以随时间变化.那么,您是在寻找没有与最初合并代码时使用的 git 版本自动合并的内容,还是与今天的 git 进行新合并的结果是什么?1

This means that what gets automatically merged is not a static thing and can change over time. So are you looking for what was not automatically merged with the git version used when the code was originally merged or what will be the result for a new merge with today's git?1

有一个 git 命令 rerere 将记录已解决的失败合并尝试,这可能是可用于提取此类信息.但它必须显式启用,它显着改变了合并处理,它只是每个存储库的设置,它只保留有限时间的历史记录并且可能会被清除,因此它远非解决方案的下降.

There is a git command rerere which will record resolved failed merge attempts, which perhaps might be used to extract such information. But it has to be explicitly enabled, it significantly changes the merge handling, it is only a per repository setting, it only keeps history for a limited time and it might be cleared, so it is far from a drop in solution.

1正如开头所指出的,这个问题的答案实际上只是尝试.

1 The answer to that question is actually just try, as pointed out in the beginning.

这篇关于如何在合并提交中列出已解决冲突的统计信息?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆