Re: Storing additional information in commit headers
From: Jeff King <hidden>
Date: 2016-06-15 22:51:42
On Mon, Aug 01, 2011 at 08:20:15PM +0200, martin f krafft wrote:
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?
This topic has come up several times in the past few years. I think some
of the relevant questions to consider about your new data are:
1. Does git actually care about your data? E.g., would it want to use
it for reachability analysis in git-fsck?
2. Is it an immutable property of a commit, or can it be changed after
the fact?
If (2) is no, then git-notes is probably the best choice.
Otherwise, if (1) is yes, then a commit header makes sense. But then, it
should also be something that git is taught about, and your commit
header should not be some topgit-specific thing, but a header showing
the generalized form.
Otherwise, the usual recommendation is to use a pseudo-header within the
body of the commit message (i.e., "Topgit-Base: ..." at the end of the
commit message). The upside is that it's easy to create, manipulate, and
examine using existing git tools. The downside is that it is something
that the user is more likely to see in "git log" or when editing a
rebased commit message.
Just about every discussion on this topic ends with the pseudo-header
recommendation. The only exceptions AFAIK are "encoding" (which git
itself needs to care about), and "generation" (which, as you noted,
raises other questions).
-Peff