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

Storing additional information in commit headers

From
MKmartin f krafft <madduck@madduck.net>
Date
Aug 1, 2011, 18:20 UTC
Message-ID
<20110801182015.GA3100@fishbowl.rw.madduck.net>
Dear list,

I've read — with great interest — the recent discussion on generation numbers[0], mostly because Clemens Buchacher pointed me to it as a warning not to mess with commit objects.

0. http://comments.gmane.org/gmane.comp.version-control.git/177146

My intent was to add an extra commit header to select commits as a way to store extra information needed to automate the management of interdependent branches and patch generation à la TopGit.

Having read the generation numbers debate, I am not sure that adding additional commit headers is a bad idea per se. From what I understand, the main pushback to Linus' idea was that people did not feel it right to store redundant, calculateable information permanently in commit objects, where they cannot be altered anymore, despite the non-zero chance of there being an error. Instead, the use of a cache was advocated. I do not want to take a side in this debate with this mail of mine.

Instead, I am investigating ways in which I can store additional information for a branch, and ideally in a way to make it transparent and automatic for all users of a project's repo.

Hence, if I were to store additional information in the commit object headers, this information would by design be correct, immutable, and non-redundant. I am going to reply to my own mail with some implementation details to feed the curious, with the hope to keep this debate focused.

Are there any strong reasons against my use of commit headers for specific, well-defined purposes in contained use-cases? E.g. are there tools known to only copy "known" headers, which could potentially break my assumptions?

Thanks,
-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"when a gentoo admin tells me that the KISS principle is good for
 'busy sysadmins', and that it's not an evolutionary step backwards,
 i wonder whether their tape is already running backwards."
 
spamtraps: madduck.bogus@madduck.net
Next: Sverre Rabbelier
Message 1 of 23 in “Storing additional information in commit headers”
  1. martin f krafftAug 1, 2011
  2. Sverre RabbelierAug 1, 2011
  3. martin f krafftAug 1, 2011
  4. Clemens BuchacherAug 1, 2011
  5. martin f krafftAug 1, 2011
  6. martin f krafftAug 1, 2011
  7. Martin LanghoffAug 1, 2011
  8. martin f krafftAug 1, 2011
  9. Jeff KingAug 1, 2011
  10. martin f krafftAug 1, 2011
  11. Jeff KingAug 2, 2011
  12. martin f krafftAug 2, 2011
  13. working prototype of orphan parent commits as datastores (was: Storing additional information in commit headers)martin f krafft, Aug 2, 2011
  14. Jeff KingAug 2, 2011
  15. martin f krafftAug 2, 2011
  16. martin f krafftAug 2, 2011
  17. Jeff KingAug 2, 2011
  18. martin f krafftAug 2, 2011
  19. per-ref data storage (was: Storing additional information in commit headers)martin f krafft, Aug 2, 2011
  20. martin f krafftAug 2, 2011
  21. Jeff KingAug 4, 2011
  22. Jeff KingAug 4, 2011
  23. Michael HaggertyAug 2, 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.