4 ms·

Git's going to have built-in "generation numbers" soon. http://permalink.gmane.org/gmane.comp.version-control.git/177146 http://permalink.gmane.org/gmane.comp.v

Git's going to have built-in "generation numbers" soon. http://permalink.gmane.org/gmane.comp.version-control.git/177146 http://permalink.gmane.org/gmane.comp.version-control.git/17... edit: jacknagel points out that they actually didn't go with this after all. Insted: https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c0d15e9e1b402ed https://github.com/git/git/commit/ffc4b8012d9a4f92ef238ff72c...

jrockway 15y ago
So imagine your history looks like this: __C__ / \ A---B---D A is commit number one. D is commit number three. If B is two, then what is C? Assuming you can come up with a consistent view when all the information about the branch topology is available, what about when people have disconnected branches? How do you avoid duplicate generation numbers? If you can't avoid duplicate generation numbers, what's the point of having them? "Fixed in commit 2." Great, which commit 2 did you mean?
- JeremyBanks 15y ago
  You have duplicates, B and C would have the same generation number. It just represents length of the longest path from the root commit. This is already calculated internally to optimize several operations, so they were considering making it part of the commit data. It often won't uniquely identify commits, but revision numbers in SVN are also sometimes used imprecisely ("oh, it was around R1500"), so I think it would have value.
  - jrockway 15y ago
    Yeah, but you know people want this so they can write things in their bug tracker like "fixed in r1232" instead of "fixed in 2c4d96d1dc2d12afd486561329a9a7b74d4ae110".
    - mullr 15y ago
      That's what `git describe` is for.
    - JeremyBanks 15y ago
      I wouldn't mind "fixed in 981db17b8 (gen 1853)".
    - stephen 15y ago
      This will give you r/1232: https://github.com/stephenh/git-central/blob/master/server/post-receive-commitnumbers https://github.com/stephenh/git-central/blob/master/server/p... (It makes a tag-per-commit; I'm not saying that's necessarily a good idea, but if you really want revision numbers...)
jacknagel 15y ago
Actually if you follow the thread(s) relating to this, a less invasive change to speed up "git tag --contains" was adopted (see git.git@ffc4b8012), so "soon" probably isn't the right word.

jrockway 15y ago

So imagine your history looks like this: __C__ / \ A---B---D A is commit number one. D is commit number three. If B is two, then what is C? Assuming you can come up with a consistent view when all the information about the branch topology is available, what about when people have disconnected branches? How do you avoid duplicate generation numbers? If you can't avoid duplicate generation numbers, what's the point of having them? "Fixed in commit 2." Great, which commit 2 did you mean?

JeremyBanks 15y ago
You have duplicates, B and C would have the same generation number. It just represents length of the longest path from the root commit. This is already calculated internally to optimize several operations, so they were considering making it part of the commit data. It often won't uniquely identify commits, but revision numbers in SVN are also sometimes used imprecisely ("oh, it was around R1500"), so I think it would have value.
- jrockway 15y ago
  Yeah, but you know people want this so they can write things in their bug tracker like "fixed in r1232" instead of "fixed in 2c4d96d1dc2d12afd486561329a9a7b74d4ae110".
  - mullr 15y ago
    That's what `git describe` is for.
  - JeremyBanks 15y ago
    I wouldn't mind "fixed in 981db17b8 (gen 1853)".
  - stephen 15y ago
    This will give you r/1232: https://github.com/stephenh/git-central/blob/master/server/post-receive-commitnumbers https://github.com/stephenh/git-central/blob/master/server/p... (It makes a tag-per-commit; I'm not saying that's necessarily a good idea, but if you really want revision numbers...)

jacknagel 15y ago

Actually if you follow the thread(s) relating to this, a less invasive change to speed up "git tag --contains" was adopted (see git.git@ffc4b8012), so "soon" probably isn't the right word.