Re: [RFC] Plumbing-only support for storing object metadata

[Derek Fawcus <dfawcus@cisco.com>]

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,  the downside being that it makes
the comments a bit ugly,  and one needs to know the protocol for
parsing them.

My other hacky thought was that tag object could be overloaded for
this purpose.  It is already sort of an indirect object,  but seems
to be limited to appearing at the edge of the graph.

If we could say have:

  commit -> tag -> tree

then arbitrary data could be stored in the tag,  similarly this
could be extended for when a tree or blob object is expected
(I'm not sure about the blob case).

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.

DF