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

Re: Git commit generation numbers

From
GSGeorge Spelvin <linux@horizon.com>
Date
Jul 17, 2011, 18:27 UTC
Message-ID
<20110717182743.14423.qmail@science.horizon.com>
Show 10 quoted lines
> The thing I hate about it is very fundamental: I think it's a hack around a basic git
> design mistake. And it's a mistake we have known about for a long time.
> 
> Now, I don't think it's a *fatal* mistake, but I do find it very broken to basically
> say "we made a mistake in the original commit design, and instead of fixing it we
> create a separate workaround for it".
> 
> THAT I find distasteful. My reaction is that if we're going to add generation
> numbers, then were should just do it the way we should have done them originally,
> rather than as some separate hack.

There are a few design mistakes in git. The way the object type and size are prefixed to the data for hasing purposes, which prevents aligned fetching from memory-mapped data in the hashing code, isn't too pretty either.

But git has generally preferred to avoid storing information that can be recomputed. File renames are the big example. given this, why the heck store generation numbers?

They *can* be computed on demand, so arguably they *should*. Cacheing is then an optimization, just like packs, pack indexes, the hashed object storage directories, and all that.

I'm in the "make it a cache" camp, honestly.

For example, here's a different possible generation number scheme. By making the generation number a cache, it becomes a valid alternative to experiment with.

Simply store a topologically sorted list of commits. Each commit's position can serve as a generation number, and is greater than the positions of all ancestors. But by using the offset within the list, the number is stored implicitly.

Generation numbers don't have to be consecutive as long as they're correctly ordered, so you could, e.g. choose to make them unique.

I don't think this is actually worth it; I'm just using it as a not-completely-insane example of a different design that nonetheless achieves the same goal.

Why freeze this in the object format?
Next: Long, Martin
Message 1 of 35 in “Re: Git commit generation numbers”
  1. George SpelvinJul 17, 2011
  2. Long, MartinJul 17, 2011
  3. Linus TorvaldsJul 17, 2011
  4. George SpelvinJul 17, 2011
  5. Linus TorvaldsJul 17, 2011
  6. George SpelvinJul 18, 2011
  7. Anthony Van de GejuchteJul 18, 2011
  8. George SpelvinJul 18, 2011
  9. Nicolas PitreJul 20, 2011
  10. George SpelvinJul 20, 2011
  11. david@lang.hmJul 20, 2011
  12. Nicolas PitreJul 20, 2011
  13. Phil HordJul 21, 2011
  14. david@lang.hmJul 21, 2011
  15. Shawn PearceJul 21, 2011
  16. Phil HordJul 21, 2011
  17. david@lang.hmJul 21, 2011
  18. George SpelvinJul 21, 2011
  19. Jakub NarebskiJul 21, 2011
  20. George SpelvinJul 21, 2011
  21. Shawn PearceJul 21, 2011
  22. Jakub NarebskiJul 22, 2011
  23. Nicolas PitreJul 22, 2011
  24. david@lang.hmJul 22, 2011
  25. Jakub NarebskiJul 22, 2011
  26. Linus TorvaldsJul 22, 2011
  27. Jeff KingJul 22, 2011
  28. Felipe ContrerasJul 28, 2011
  29. Ramkumar RamachandraSep 6, 2011
  30. david@lang.hmJul 22, 2011
  31. Nicolas PitreJul 22, 2011
  32. david@lang.hmJul 22, 2011
  33. Phil HordJul 21, 2011
  34. Nicolas PitreJul 21, 2011
  35. Phil HordJul 21, 2011

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.