Re: [PYRITE] Status update and call for information.

> 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:
>