4 ms·

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 wou

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?
    - fanf2 15y ago
      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.

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?
  - fanf2 15y ago
    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.