Re: Storing additional information in commit headers

From: Jeff King <peff@peff.net>
Date: Aug 1, 2011, 20:13 UTC
Message-ID: <20110801201301.GA17111@sigill.intra.peff.net>
In-Reply-To: <20110801182015.GA3100@fishbowl.rw.madduck.net>

On Mon, Aug 01, 2011 at 08:20:15PM +0200, martin f krafft wrote:

Show 14 quoted lines

> 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