martin f krafft | 1 Aug 20:20 2011

Storing additional information in commit headers

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.


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?



martin | |

"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 <at>