5 ms·

OK, finally found a decent explanation of what a Git generation number actually IS: http://www.spinics.net/lists/git/msg161165.html http://www.spinics.net/list

OK, finally found a decent explanation of what a Git generation number actually IS: http://www.spinics.net/lists/git/msg161165.html http://www.spinics.net/lists/git/msg161165.html

pak 15y ago
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.
- davvid 15y ago
  "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.
andrewflnr 15y ago
So it's almost, but not quite, like the revision numbers everyone else has always had?
- iclelland 15y ago
  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.
  - jbert 15y ago
    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?
    - noste 15y ago
      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 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.
      - jbert 15y ago
        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?
    - stonemetal 15y ago
      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.
      - jbert 15y ago
        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?
- praptak 15y ago
  They are somewhat between revision numbers and vector clocks.
tonfa 15y ago
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.

OK, finally found a decent explanation of what a Git generation number actually IS: http://www.spinics.net/lists/git/msg161165.html http://www.spinics.net/lists/git/msg161165.html

pak 15y ago

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.

davvid 15y ago
"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.

andrewflnr 15y ago

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

iclelland 15y ago
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.
- jbert 15y ago
  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?
  - noste 15y ago
    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 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.
    - jbert 15y ago
      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?
  - stonemetal 15y ago
    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.
    - jbert 15y ago
      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?
praptak 15y ago
They are somewhat between revision numbers and vector clocks.

tonfa 15y ago

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.