also sprach Jeff King <peff@xxxxxxxx> [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@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)