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@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)