“责备”命令的简化语义是一件好事吗？
我正在研究一种新的基于织物的数据结构来存储版本控制历史。 这无疑会引发一些宗教的战争，是否是正确的做法，但这不是我现在的问题。
我的问题与输出责任应该给予什么。 当一行代码被添加，删除，并合并到自己多次，并不总是清楚什么修订应该是责怪它。 值得注意的是，这意味着当一段代码被删除时，它的所有logging已经消失了，并且没有责任去除。 我曾经与这个问题交往过的每个人都表示，试图做得更好就是不值得的。 有时候，人们把这个被删除的部分后面的那一行的内容，从删除的那一部分改为修改的时候，就会把这个责任改变了。 据推测，如果该部分是在最后，最后一行得到的责备改变，如果文件结束空责任真的消失在以太，因为几乎没有任何地方留下的责备信息。 由于各种技术原因，我不会使用这个黑客攻击，但是假设持续的，但是这个完全没有logging但事实上的标准实践将是没有争议的（但是可以随意激发我，并将它从你的系统中取出）。
转到我的实际问题。 对于每一行，通常应该指责它们在历史中被添加和删除的完整历史，并且使用三向合并（或者在交叉合并的情况下是随机废话），并且基于这些关系你根据它的历史来确定这条线是否应该在那里，如果它不应该，那么你用现在的修订标记它是新的。 如果一条线出现在不同责任的多个祖先中，则select哪一个任意inheritance。 再次，我认为继续这种完全没有logging但事实上的标准做法是没有争议的。
我的新系统分歧的地方在于，不是根据对整个历史的复杂计算，而是对现行版本是否应该进行复杂的计算，而只是看直接的祖先，如果是在任何他们挑选一个任意的inheritance责任。 我在很大程度上是因为技术上的原因进行了这种改变（其他的指责实现完全可能做同样的事情，由于类似的技术原因和缺乏关怀），但考虑到这一点后，我实际上更喜欢新的行为比旧的更直观，更可预测。 大家怎么想？
实际上我写了一个这样的责任实现（ Subversion当前的一个我相信，除非有人在过去的一两年内取代它）。 我也帮助了一些其他人。
至less大多数责任的实现不会做你所描述的：
通常在每一行的责备，你看完整的历史，在历史上被添加和删除，并使用三种方式合并（或在纵横交错的情况下，随机废话），并基于你们之间的关系根据历史logging确定该行是否应该在那里，如果不是，那么在当前修订中将其标记为新的。 如果一条线出现在不同责任的多个祖先中，则select哪一个任意inheritance。 再次，我认为继续这种完全没有logging但事实上的标准做法是没有争议的。
实际上，大多数的指责比这个要复杂得多，根本不用费力去使用这些关系，但是他们只是按照任意的顺序走父母，使用简单的三angular结构（通常是相同的内部结构，它把它变成文本输出），看看块是否改变了，如果是的话，责备它，并将该行标记为完成。
例如， Mercurial只是进行迭代深度优先search，直到所有行被指责为止。 它没有试图考虑到这种关系是否使它不可能把责任归咎于正确的关系。
Git确实做了一些更复杂的事情，但仍然不像你所描述的那样。
Subversion是做Mercurial的，但是历史图很简单，所以更简单。
反过来说，你所暗示的是，实际上，他们真正做的是什么：
挑选一个任意的祖先，沿着兔子洞的这条path走下去，直到完成，如果它不会导致你责备所有的线，任意select下一个祖先，继续，直到所有的责任被分配。
在个人层面上，我更喜欢你的简化选项。
原因：无论如何，责备不是非常使用。
所以我没有看到浪费大量时间来全面实施它。
这是真的。 指责已经在很大程度上成为那些“彩虹底”的特征之一。 从我们这些站在地上的人看来，这真的很酷，我们梦想有一天我们可以点击一个文件，看看谁写了哪行代码。 但是现在它被广泛的实施，我们大多数人已经意识到它实际上并不是很有帮助。 在Stack Overflow上检查blame标签上的活动。 它是低落的荒凉。
在最近几个月里，我已经跑过了几十个“非常值得”的情景，而且在大多数情况下，我试图首先使用责任，发现它很繁琐或完全无益。 相反，我通过对有问题的文件执行一个简单的过滤更新日志，find了我需要的信息。 在某些情况下，如果我坚持不懈，我本可以用“责备”来find这些信息，但要花更长的时间。
主要问题是代码格式更改。 几乎所有的一切责任被列为…我！ 为什么？ 因为我是一个负责修复换行符和制表符，重新sorting函数顺序，将function拆分成单独的实用程序模块，修复注释错误，改进或简化代码stream的人员。 如果不是我，其他人也做了一个空白，或者沿着这个方向移动。 为了对任何可以追溯到一段时间的事情都有一个有意义的指责，那就是我不能在没有怪的帮助下已经记得，所以我不得不放弃修改和重新指责。 再次责怪。 然后再次。
因此，为了让责备实际上成为比最幸运的情况更有用的时间保护者，责备必须能够启发性地超越换行，空白，并理想地阻止复制/移动改变。 这听起来像是一个非常高的顺序，特别是当为单个文件扫描更新日志时，大多数情况下，它不会产生很多差异，而且可以很快地通过手工筛选。 （值得注意的例外，可能是devise非常糟糕的源代码树，其中90％的代码被塞进了一两个巨大的文件中……但是现在在一个协作编码环境中，谁又做了这么多事情？）。
结论：给它一个赤裸裸的执行责任，因为有些人喜欢看到“它可以责怪！” 在function列表上。 然后转移到重要的事情上。 请享用！
行合并algorithm比开发者更笨拙。 如果他们不同意，这只是表明合并是错误的，而不是表明一个决定点。 所以，简化的逻辑应该更加正确。
