From: "Shawn O. Pearce" <spearce@spearce.org>
To: Derek Fawcus <dfawcus@cisco.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Plumbing-only support for storing object metadata
Date: Mon, 18 Aug 2008 16:18:44 -0700 [thread overview]
Message-ID: <20080818231844.GC9572@spearce.org> (raw)
In-Reply-To: <20080818230646.GA11044@cisco.com>
Derek Fawcus <dfawcus@cisco.com> wrote:
> On Sun, Aug 17, 2008 at 11:12:36PM -0700, Shawn O. Pearce wrote:
> > Adding a new type bit is a lot more than just adding it to the pack
> > data field. Look at the amount of code that needed to be changed to
> > support gitlink in trees, and that was "reusing" the OBJ_COMMIT type.
> > Anytime you start poking at the core object enumeration code with
> > new cases there's a lot of corners that are affected.
>
> Actually, I'd been thinking of how to attach metadata - but more from
> the perspective of attaching it to commits, rather than individual
> blobs or trees.
>
> At the moment, my workaround is simply to add well known lines to
> the end of the commit comments,
We've talked about adding additional header lines to the commit after
the "committer" or "encoding" line but before the first blank line
that ends the headers and starts the message. Most of the code will
skip over an unknown header at this position, as we went through
that pain when we added the "encoding" header to the commit format.
However, once you start putting headers into there one has to
actually understand what they mean. And it gets really ugly if
your tool thinks "fixed XXX\n" means something different from what
my tool thinks "fixed YYY\n" means and I use my tool against a
clone of your repository. In other words there is no concept of
"header namespaces".
Thus far I don't think anyone has really tried adding more headers
here because nobody has come up with a concrete example of how it
is useful.
> I guess there'd have to be some rule - like only one indirect
> object allowed to be inserted (otherwise its awkward to check
> for loops), and there would need to be some custom merge rules.
Loops aren't possible. If you can create a loop you have a very
real and very valid attack against SHA-1. You will probably be
able to use that in some way that profits you better than a loop
within some random Git repository.
You may also want to look into the "notes" idea floated on the list
in the past. It allowed attaching trees (IIRC) to any commit, and
finding that later on in O(1) time during say git-log. This can
be useful to attach a build report or a test report to a commit
hours after it was created.
--
Shawn.
next prev parent reply other threads:[~2008-08-18 23:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-09 21:07 [RFC] Plumbing-only support for storing object metadata Jamey Sharp, Josh Triplett
2008-08-09 21:49 ` Scott Chacon
2008-08-10 3:51 ` Shawn O. Pearce
2008-08-10 11:20 ` Stephen R. van den Berg
2008-08-10 12:16 ` david
2008-08-10 14:50 ` Jan Hudec
2008-08-10 17:57 ` Stephen R. van den Berg
2008-08-10 18:11 ` Jan Hudec
2008-08-10 20:16 ` Stephen R. van den Berg
2008-08-10 22:34 ` Junio C Hamano
2008-08-10 23:10 ` david
2008-08-11 10:11 ` Stephen R. van den Berg
2008-08-16 6:21 ` Josh Triplett, Jamey Sharp
2008-08-16 7:56 ` david
2008-08-16 9:55 ` Junio C Hamano
2008-08-16 15:07 ` Jan Hudec
2008-08-18 6:12 ` Shawn O. Pearce
2008-08-18 23:06 ` Derek Fawcus
2008-08-18 23:18 ` Shawn O. Pearce [this message]
2008-08-18 23:23 ` Marcus Griep
2008-08-18 23:28 ` Shawn O. Pearce
2008-08-10 11:09 ` Jan Hudec
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080818231844.GC9572@spearce.org \
--to=spearce@spearce.org \
--cc=dfawcus@cisco.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).