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

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

问题描述

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

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回答:只需尝试.

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.

现在,您可能会说您对自动合并失败感兴趣,而实际上没有冲突.足够公平,但是这完全取决于所使用的工具.例如,如果彼此相邻的两行被修改,而 KDiff3 不会被修改,则Git的内部合并处理将失败.通常是您想要的,但是与分开的行相比,这种错误的风险更大,因此需要权衡取舍.

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天全站免登陆