On Fri, May 23, 2008 at 1:45 AM, Karl Hasselström <kha@xxxxxxxxxxx> wrote: > On 2008-05-23 01:18:42 -0500, Govind Salinas wrote: > >> Some functionality isn't for everyone. I have just put into my next >> branch an addon that gives git revision numbers. Why, because other >> SCMs that are supposed to be more user friendly have them. Because >> people have been asking for them. Because they are easier to >> remember. The concept is this. A given commit encapsulates its >> parantage, so if I have commit XYZ, I can always say that XYZ is >> so-many commits away from the first commit. The question is how you >> determine that number and that you always do it the same. If we just >> define the revision number to be the place of the commit in the list >> of "git rev-list --topo-order --reverse SHA1" then we can get a >> consistant number semi-meaningful number, which is all people really >> want. > > You do realize that no matter how you define your sequential numbers, > they can't be both globally consistent and unique? (That is, either > different repositories will assign different numbers to the same > commit, or the same number could be assigned to more than one commit.) > > For a simple reason: A numbering that's both globally consistent and > unique can only look at a commit's ancestry (and the commit itself) > when assigning a number to a commit. But in order to get _sequential_ > numbers, you need to look at the commit's siblings as well, and the > set of siblings can be different from repository to repository. > > This has already been discussed to death elsewhere in this list at > least once (see the list archives), but your next paragraph suggests > you think it's only a performance issue, which is why I brought it up: > Of course, no one makes the claim that rev numbers are unique or even that a commit has the same revision number between branches in the same repository. Hg states that flat out and I believe bzr says the same, although I am pretty sure they determine their numbers some other way. I make no such claim. What I do claim is that for a given branch, a commit should always have the same revision number. Sure, If you merge a commit from another branch, it's revnum might change, but that is ok. As long as, assuming you have not re-written master, 10:master will always point to the same commit I think I am providing something worth while. Also, AFAIK the order of parentage is part of the hash that makes a commit ID, so if my master is a clone of your master, it should share revision numbers. Thanks, Govind. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
