version-control - 'blame' 命令的简化语义是一件好事吗？

Question

我正在开发一个新的 weave用于存储版本控制历史的基于数据结构。毫无疑问，当它问世时，这会引起一些关于它是否是正确的做事方式的宗教 war ，但这不是我现在的问题。

我的问题与输出 blame 有关应该给。当一行代码被多次添加、删除和合并时，并不总是清楚哪个版本应该为此负责。值得注意的是，这意味着当删除一段代码时，该段代码的所有记录都消失了，并且删除不会受到任何指责。与我讨论过这个问题的每个人都说，试图做得更好根本不值得。有时，人们会修改被删除部分后面的行，将其责任从实际内容更改为该部分被删除时的修订版本。据推测，如果该部分位于末尾，那么最后一行的责备就会发生变化，如果文件最终为空，那么责备确实会消失在以太中，因为实际上没有地方可以放置责备信息。由于各种技术原因，我不会使用这个 hack，但假设继续使用这种完全没有记录但事实上的标准实践将是没有争议的(但请随意攻击我并将其从你的系统中删除)。

继续我的实际问题。通常，对于每一行，您都会查看其在历史记录中添加和删除位置的完整历史记录，并使用三向合并(或者，在交叉合并的情况下，随机废话)并基于这些行之间的关系您可以根据其历史记录来确定该行是否应该存在，如果不应该存在，那么您可以使用当前修订版将其标记为新的。如果某一谱系出现在具有不同责任的多个祖先中，那么它会任意选择继承哪一个。再次，我认为继续这种完全没有记录但事实上的标准实践将是没有争议的。

我的新系统的不同之处在于，它不是根据整个历史记录的复杂计算来计算给定的行是否应该在当前版本中，而是简单地查看直接的行祖先，如果该血统属于其中任何一个，它就会选择任意一个来继承责任。我之所以做出这样的改变主要是出于技术原因(而且其他的指责实现完全有可能出于类似的技术原因和缺乏关心而做同样的事情)，但在考虑之后，我的一部分实际上更喜欢新的行为，因为比旧的更加直观和可预测。大家觉得怎么样？

Answer 1

我实际上写了一个指责实现(我相信 Subversion 是当前的实现，除非有人在过去的一两年内替换了它)。我也帮助了其他一些人。

至少大多数指责的实现都不会执行您所描述的操作:

Usually in blame for each line you look at the complete history of where it was added and removed in the history and using three way merge (or, in the case of criss-cross merges, random bullshit) and based on the relationships between those you determine whether the line should have been there based on its history, and if it shouldn't but is then you mark it as new with the current revision. In the case where a line occurs in multiple ancestors with different blames then it picks which one to inherit arbitrarily. Again, I assume that continuing with this completely undocumented but de facto standard practice will be uncontroversial.

实际上，大多数责备远没有这那么复杂，并且根本不费心去尝试使用这些关系，但它们只是以某种任意顺序遍历父级，使用简单的增量结构(通常是相同的内部结构，无论它们采用何种 diff 算法)在将其转换为文本输出之前使用)来查看 block 是否已更改，如果是，则归咎于它，并将该行标记为已完成。

例如，Mercurial只是进行迭代深度优先搜索，直到所有行都被归咎为止。它不会尝试考虑这些关系是否使其不太可能归咎于正确的人。

Git确实做了一些更复杂的事情，但仍然不太像你描述的那样。

Subversion 的功能与 Mercurial 的功能相同，但历史图表非常简单，因此更加简单。

反过来，您所建议的实际上是他们真正所做的:

选择一个任意的祖先，然后沿着兔子洞的路径走下去，直到完成，如果它不会导致你责怪所有的行，则任意选择下一个祖先，继续，直到分配了所有的责备。