Re: Storing additional information in commit headers

also sprach Jeff King [off-list ref] [2011.08.01.2213 +0200]:

This topic has come up several times in the past few years.

I am sorry that I am bothering the list again. I tried hard to find
whatever I could, but after 2–3 hours of web searching, I came here…

Thank you for taking the time to answer!

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?

Excellent points, and I have answers to both:

  1. Ideally, I would like to point to another blob containing
     information. Right now, in order to prevent gc from pruning
     it, that would have to be a commit pointed to with a parent
     pointer, which is just not right (it's not a parent) and causes
     the commit to show up in the history (which it should not, as
     it's an implementation detail).

     I'll return to this point further down…

  2. It is immutable. Ideally, I would like to store extra
     information for a ref in ref/heads/*, but there seems to be no
     way of doing this. Hence, I need to store it in commits and
     backtrack for it. Or so I think, at least…

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.

I agree entirely and would be all too excited to see this happening.
I already had ideas too:

  In addition to the standard tree and parent pointers, there could
  be *-ref and x-*-ref headers, which take a single ref argument,
  presumably to a blob containing more data.

  While I cannot conceive a *-ref example, I think it's obvious that
  x-*-ref should be introduced at the same time to keep the *-ref
  namespace clear for future, "official" Git use.

  In terms of gc and fsck and the like, all *-ref and x-*-ref
  headers would contribute to reachability tests and hence prevent
  pruning of those blobs.

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.

… to see *and to accidentally mess up*. And while that may even be
unlikely, it does expose information that really ought to be hidden.

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).

I can see how it's arguable too why one would want to give git
commit objects the ability to reference arbitrary blobs containing
additional information. I suppose the answer to this question is
related to the answer to the question of whether Git is
a contained/complete tool as-is, or also serves as
a "framework"/"toolkit" for advanced/creative use.

The availability of the porcelain commands seems to suggest that
extensible/flexible additional features should be welcome! ;)

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
http://www.transnationalrepublic.org/
 
spamtraps: madduck.bogus@madduck.net