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: > So why isn't this for everyone? Because its a little slow and some > people on the list HATE anything that takes more than half a second. > I won't name names but he has an OS named after him. So for a git > repo on decent hardware, this adds .5-1 seconds to look something up > and find out its revision. Painful to some, but others would rather > wait than have to try and remember a SHA1 or even just the first 8 > chars of a SHA1. > Well, this mail is long enough, hopefully I will get some feedback > on this, some more ideas for things that can be simplified or > enhanced or whatever. Please feel free to drop me a line and/or > check out my public repo at http://gitorious.org/projects/pyrite. Good luck with your work! -- Karl Hasselström, kha@xxxxxxxxxxx www.treskal.com/kalle -- 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
