我如何证明我用K&R,而不是B&D作为编码标准获得的使用Git冲突最小的数字?

Git是聪明,将“跟随”在历史上的变化,使合并对我来说更容易和经销商的合并等等。 冲突是由没有围绕变化而变化的线划定。 随着K&R你得到的只有暧昧没有行“{”在其中,就像您在B&D。 如何将测试的Git在围绕一个变化的线条而言上下文敏感的限制?

我想避免解决,我可能不需要冲突。 但我需要一些方法来测试我有多少潜在的冲突通过切换到K&R和它带来的更多的情况下保存。

到目前为止,Git是太聪明的话,被简单的例子上当。

任何帮助表示赞赏。 提前致谢。

--------------解决方案-------------

所以这是我迄今发现的证据来此最接近。
http://git.661346.n2.nabble.com/Bram-Cohen-speaks-up-about-patience-diff-td2277041.html

电子邮件正在讨论中的Git了“耐心”算法的目的。 在它布拉姆解释是多余的匹配行如何创建讨厌的冲突可以是很难解决,但只有在涉及大片相当复杂的合并的情况。 换句话说简单的例子做作将无法显示此行为。

虽然他确实也不在话下之类的东西最终影响结果是有一定道理推断,将开括号在它自己的行会增加多余的匹配行可能导致这些冲突的概率更大的数量。

我说这不是铁板一块,但它确实有助于一些可信这一理论。

所以,“唯一的行'是'不重要线”一个简单的跨语言的代理。

这一报价脱颖而出,我在这次讨论中,因为我们什么,我们觉得基本上是匹配的,都应该给我们环境的重要线路,但梅开二度本身并不重要,但不再提供上下文。

挑选标准,是您更容易/你的团队读了别的。 不管你的源代码控制系统今天的行为方式会表现得更加美好的明天,但你的代码会留你检查它在很长一段时间的方式。

我们有几个大项目(超过200码的文件),它同时包含K&R和B&D的大量混合物。 我可以肯定地说,在Git里,一个开发人员正在重构,疯了,一个重订基期的行为“几个一天的时间”后,近2年来,我从未有过冲突,由于编码标准的东西。 因此,选择哪一个,或两者,或两者都不是。 这并不重要。

分类:C# 时间:2012-07-07 人气:0
分享到:

相关文章

Copyright (C) 55228885.com, All Rights Reserved.

55228885 版权所有 京ICP备15002868号

processed in 2.111 (s). 10 q(s)