git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Karl Hasselström <kha@treskal.com>
Date
May 23, 2008, 06:45 UTC
Message-ID
<20080523064541.GA31315@diana.vm.bytemark.co.uk>
In-Reply-To
<5d46db230805222318j25657c10t2955fbdf1aa5c003@mail.gmail.com>
On 2008-05-23 01:18:42 -0500, Govind Salinas wrote:
Show 12 quoted lines
> 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:

Show 7 quoted lines
> 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@treskal.com
      www.treskal.com/kalle
Previous: Govind SalinasNext: Govind Salinas
Message 2 of 18 in “[PYRITE] Status update and call for information.”
  1. Govind SalinasMay 23, 2008
  2. Karl HasselströmMay 23, 2008
  3. Govind SalinasMay 23, 2008
  4. Karl HasselströmMay 23, 2008
  5. Jakub NarebskiMay 24, 2008
  6. Govind SalinasMay 24, 2008
  7. Jakub NarebskiMay 24, 2008
  8. Govind SalinasMay 24, 2008
  9. Jakub NarebskiMay 24, 2008
  10. Jan KruegerMay 25, 2008
  11. Govind SalinasMay 25, 2008
  12. Dmitry PotapovMay 24, 2008
  13. Jakub NarebskiMay 24, 2008
  14. Govind SalinasMay 24, 2008
  15. Jakub NarebskiMay 25, 2008
  16. Govind SalinasMay 25, 2008
  17. Dmitry PotapovMay 24, 2008
  18. Jakub NarebskiMay 24, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.