我正在研究一个新的基于weave的数据结构，用于存储版本控制历史记录。毫无疑问，这是否会引发一些宗教 war ，即它是否是《正确的做事方式》，但这不是我现在的问题。
我的问题与blame应该提供什么输出有关。当一行代码被添加，删除和合并多次后，并不总是清楚应该归咎于哪个版本。值得注意的是，这意味着当删除一段代码时，该段代码中的所有记录都消失了，删除该段代码也无可厚非。我遇到这个问题的每个人都说，尝试做得更好根本不值得。有时，人们会抱怨说，删除该部分之后的行应归咎于从实际删除更改为删除该部分时的修订。据推测，如果该部分在末尾，那么最后一行的责任就变了，如果文件结束时是空的，那么责任实际上就消失了，因为实际上没有地方可放责任信息。出于各种技术原因，我不会使用此hack，但是假设继续进行但没有完全记录但实际上是标准的做法将是没有争议的(但是请随意解雇我并将其从系统中删除)。
继续我的实际问题。通常每行都怪罪于您查看历史记录中添加和删除位置的完整历史记录，并使用三向合并(或纵横交错合并，是随机胡说)，并基于两者之间的关系您可以根据其历史记录确定该行是否应该在那儿，如果不是，则将其标记为当前修订版的新行。如果在有不同责任的多个祖先中出现一条线，则它会选择任意继承的那一条。同样，我认为继续进行完全没有记载但实际上是标准的做法将不会引起争议。
我的新系统与众不同之处在于，它不是基于对整个历史的复杂计算来对给定的行是否应该在当前修订版中进行复杂的计算，而只是查看直系祖先，以及该行是否位于他们选择了任意一种来继承责任。我之所以做出此更改，主要是出于技术原因(出于类似的技术原因并且缺乏照顾，其他怪怪的实现也有可能做同样的事情)，但是在考虑了一下之后，我当中的一部分实际上更喜欢新行为，因为比旧版本更直观，更可预测。大家怎么想？
最佳答案
实际上，我在那里写了一个怪怪的实现(我相信Subversion是当前的实现，除非在过去一两年中有人替换了它)。我也帮助了其他一些人。
至少，大多数的非理性实现都没有做到您所描述的:
实际上，大多数责任并不比这复杂得多，也根本不用理会这些关系，但他们只是使用简单的delta结构(通常使用相同的内部结构，而不管以前使用的diff算法)以某种任意顺序遍历 parent 。它将其转换为文本输出)，以查看该块是否已更改，如果是，则怪它，并将该行标记为完成。
例如，Mercurial只是进行迭代深度优先搜索，直到所有行都被指责为止。它没有试图考虑这种关系是否使它不太可能归咎于正确的人。
Git确实做了一些复杂的事情，但是仍然不像您描述的那样。
Subversion可以完成Mercurial的工作，但是历史记录图非常简单，因此更加简单。
反过来，您所建议的实际上是所有这些工具真正执行的操作:
选择一个任意的祖先，并沿着兔子洞的那条路一直走下去，直到完成为止；如果它没有导致您怪罪所有的行，请任意选择下一个祖先，继续直到所有的罪魁祸首被分配为止。
关于version-control - 'blame'命令的简化语义好吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14077470/