also sprach martin f krafft <madduck@xxxxxxxxxxx> [2011.08.01.2020 +0200]: > 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. For lack of a better idea (cf. [0]), I am currently toying with the following approach: Possibly in addition to the orphan parent pointer to a commit object suggested in [0], and in order to provide a clear means to identify said orphan parent pointer (holding additional information), I am considering storing this orphan parent commit's ref in the main commit, using a header like x-topgit-top-base [1]. 0. http://permalink.gmane.org/gmane.comp.version-control.git/178349 1. The use of the x- prefix is obviously intentional to suggest that this is a free-form, non-standard extension. Whenever the extra data need changing, a new x-topgit-top-base ref is added to HEAD. Now, given a commitish, I simply have to walk back in time until I find a commit object with such a header, and I have the most recent metadata at my fingertips. Instead of a ref to the orphan parent commit (which visibily pollutes the history), I could also just store the information right there. This is arguably hackish, but unless I find a better way, it's the best I've come up with thus far. And of course, this could go into the commit message body text, but it being an implementation detail, that's really not the right place for it. Thanks for your consideration, -- martin | http://madduck.net/ | http://two.sentenc.es/ "there are two major products that come out of berkeley: lsd and unix." one caused me an addiction -- fyodor spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)