什么是 git 提交生成编号 ( hacker news link )，它们的意义是什么？

最佳答案

只是添加到 siri的 answer ，“提交生成编号”是:

• explained here :

A commit's generation is its height in the history graph, as measured from the farthest root. It is defined as:

• If the commit has no parents, then its generation is 0.
• Otherwise, its generation is 1 more than the maximum of its parents generations.

• 2005 年创建 Git 时已经提到的一个老话题:

Linus Torwald (yester, July 14th):
Ok, so I see that the old discussion about generation numbers has resurfaced.
And I have to say, with six years of git use, I think it's not a coincidence that the notion of generation numbers has come up several times over the years: I think the lack of them is literally the only real design mistake we have.
[...]
It actually came up as early as July 2005, so the "let's use generation numbers in commits" thing is really old.

• 关于快速了解一个提交是否是另一个提交的祖先的问题(无需返回 DAG——提交图——):

I think it's entirely reasonable to say that the issue basically boils down to one git question: "can commit X be an ancestor of commit Y" (as a way to basically limit certain algorithms from having to walk all the way down). We've used commit dates for it, and realistically it really has worked very well. But it was always a broken heuristic.

So yes, I personally see generation counters as a way to do the commit date comparisons right. And it would be perfectly fine to just say "if there are no generation numbers, we'll use the datestamps instead, and know that they could be incorrect".

That "use the datestamps" fallback thing may well involve all the heuristics we already do (ie check for the stamps looking sane, and not trusting just one individual one).

正如 Hacker 新闻线程提到的:

Generation numbers are a result of the state of the tree, while timestamps are derived from the ambient (and potentially incorrect!) environment from which the commit was made.

At the moment, each commit stores a reference to the parent tree.
By parsing that tree and reading the entire history you can obtain a hierarchy of commits.
Because you need to order commits in many situations, reading the entire history is extremely inefficient, so git uses timestamps to determine the ordering of commits.
This of course fails if the system clock on a given machine is off.
With a generation number, you can get an ordering locally from the latest commits, without having to rely on timestamps or read the entire tree.

When you have a commit with generation n, any later commits that include it wound have generation >n, so to tell the relation between commits, you only need look as far back as n, and you can immediately get the order of any intermediate commits.
It has nothing to do with "easy to remember". It's about making git more efficient and robust

• 不多余:

Generation numbers are completely redundant with the actual structure of history represented by the parent pointers.

莱纳斯:

Not true. That's only true if you add "... if you parse the whole history" to that statement.
And we've never parsed the whole history, because it's just too expensive and doesn't scale. So right now we depend on commit dates with a few hacks.
So no, generation numbers are not at all redundant. They are fundamental. It's why we had this discussion six years ago.

关于将该信息缓存到哪里(或者是否应该缓存)仍然存在争论，但从用户的角度来看，它仍然是关于一些“易于内存”的信息(这不是目标提交代号):

So it's almost, but not quite, like the revision numbers everyone else has always had?

是的——差不多，但不完全是。
如果你和我各自创建一个分支，使用 gen #123，那么，据我所知，我分支中的后续提交将是 #124，#125 等，您在分支中的提交也将是 #124、#125 等

对比一下: - 使用 CVS，我会有 1.124.1.1、1.124.1.2 等，而你会有 1.124.2.1、1.124.2.2，或 - 在 Subversion 中，我可能会得到修订版 125、128 和 129，而服务器给了你的提交 #124、127 和 130，以及项目完全不同部分的其他人得到了 #126。

只要开发在单个分支上线性进行，那么是的，它是关于在集中式 RCS 中保存为修订号的——但是，一旦您开始分支和 merge ，它就完全代表了一个不同的概念。

对于单个存储库，它与 svn revnos 的解释非常相似。
您可以在特定存储库中谈论“分支的修订 #125”。这通常正是您在关于发展的人与人之间的交流中所需要的。
“你能看看那个错误是否在 unstable 的 r125 中吗？” “我已经获得了 r245 产品的所有更改”
我想令人困惑的方面是，如果中央服务器中的“r245 of prod”在我的本地仓库中是“r100 of prod”，因为我没有克隆完整的历史记录？

关于Git 提交生成编号，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6702821/