Hacker News Reader

Comment by breckinloggins | Hacker News Reader

OK, finally found a decent explanation of what a Git generation number actually IS:

http://www.spinics.net/lists/git/msg161165.html

Beisdes analyzing properties of the commit graph, which doesn't seem to be a common task, what about them is so useful that they need to be stored in commit headers now? For instance, what day-to-day operations do they actually make faster? At first, it sounded like it might be for easier navigability (e.g. expanding git-rev-parse) but I don't see that in this description.

"git tag --contains" needs to know the generation number of old tags, which is expensive to calculate. "git describe" would be faster for the same reason.

Interesting. It's also nice to see that Mercurial got this right from the start (it is not generation numbers, but the rev numbers can be used in the same way to stop the exploration).

Some mistakes were made while designing Mercurial, this wasn't one of them.

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

Yes -- almost, but not quite. If you and I each create a branch off of a commit with gen #123, then, as I understand it, the subsequent commits in my branch would be #124, #125, etc., and your commits in your branch would also be #124, #125, etc.

Contrast this with CVS, where I would have 1.124.1.1, 1.124.1.2, erc., and you would have 1.124.2.1, 1.124.2.2, or with Subversion, where I might get revisions 125, 128, and 129, while the server gave your commits #124, 127 and 130, and someone else, on a totally different part of the project got #126.

As long as development proceeds linearly, on a single branch, then yeah, it's about the save as revision numbers in a centralized RCS -- once you start branching and merging, though, it represents a different concept entirely.

For a single repository, it does have a very similar interpretation to, say, svn revnos.

You can speak of "revision #125 of a branch" in a specific repository. Which is generally exactly what you need for human-to-human communication about development.

"Can you see if that bug is in r125 of unstable?" "I've got all changes up to r245 of prod"

I guess the confusing aspect would be if "r245 of prod" in the central server was "r100 of prod" in my local repo because I haven't cloned the full history?

It would appear to me that multiple commits in a branch can have the same generation number (see the diagram in http://www.spinics.net/lists/git/msg161165.html ). So unless your history is linear, using generation numbers in human-to-human communication may get confusing really fast.

In that diagram, I see 2 sequences of commits (two branches).

The 'original branch' (e.g. "unstable") goes: 0,1,2,5,6

Then there is a topic branch (e.g. "add-frob"), which goes: (0,1),2,3,4,(5). Note that I consider the the 'add-frob' branch ended at the merge commit, so there is no "revno 6 of 'add-frob').

I don't consider that merging 'add-frob' back into unstable means that "revno 2 in unstable" could mean commit D - I would call commit D "revno 2 in add-frob".

Does that system work?

No there isn't a similarity to svn revnos. Rev 125 of a branch in a repo isn't a specific commit it is a specific depth in the tree. In your example you couldn't talk about a singular Rev 125 unless there really was one Rev 125. These numbers wouldn't be like Hg's revnos they would be stable across clones.

My intention was that a single branch could have an unambiguous revno.

As pointed out elsewhere in the thread, that requires that branch identity is maintained across a fork+merge, but that seems reasonable to me?

In git, a branch is just a ref that points to the most recent commit in a development series. The history of the branch has no explicit link to the branch name. Individual commits do not belong to a branch. So the commits in the history of a single branch will not have unique generation numbers.

They are somewhat between revision numbers and vector clocks.

Reply on news.ycombinator.com