Re: Storing additional information in commit headers

From: martin f krafft <madduck@madduck.net>
Date: Aug 1, 2011, 21:11 UTC
Message-ID: <20110801211104.GC15401@fishbowl.rw.madduck.net>
In-Reply-To: <20110801201301.GA17111@sigill.intra.peff.net>

also sprach Jeff King <peff@peff.net> [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!

Show 8 quoted lines

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

Show 6 quoted lines

> 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