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

[Junio C Hamano <gitster@pobox.com>]

"Stephen R. van den Berg" <srb@cuci.nl> writes:

> I agree that using a custom rare extension would allow for almost no
> change to git-core.

And at that point there is no "plumbing" side change necessary.  You just
have to teach your Porcelain to notice the associated "metainfo" files and
deal with them.

For merging such "metainfo", you would need to do your "flattish/unrich"
checkout anyway, so it might be that an easier approach for such a
Porcelain might be:

 * Define a specific leading path, say ".attrs" the hierarchy to store the
   attributes information.  Attributes to a file README and t/Makefile
   will be stored in .attrs/README and .attrs/t/Makefile.  They are
   probably just plain text file you can do your merges and parsing easily
   but with this counterproposal the only requirement is they are simple
   plain blobs.  The plumbing layer does not care what payload they carry.

 * When you want to "git setattr $path", the Porcelain mucks with
   ".attr/$path".  Probably checkout codepath would give you a hook that
   lets you reflect what ".attr/$path" records to "$path", and checkin
   (i.e. not commit but update-index) codepath would have another hook to
   let you grab attributes for "$path" and update ".attr/$path".

 * Merging and handling updates to ".attrs/" hierarchy are done the usual
   way we handle blobs.  Your Porcelain would then take the result and do
   whatever changes to ACL or xattrs to the corresponding path, perhaps
   from a hook after merge.

So it will most likely boild down to a "Porcelain only" convention that
different Porcelains would agree on.

My reaction for the initial proposal was very similar to the one given by
Shawn.  I do not see much point on having plumbing side support (yet).