From: david@lang.hm
Date: Sun, 10 Aug 2008 23:10:44 GMT
Subject: Re: [RFC] Plumbing-only support for storing object metadata
Message-ID: <alpine.DEB.1.10.0808101550570.32620@asgard.lang.hm>
In-Reply-To: <7v7iao1oua.fsf@gitster.siamese.dyndns.org>

On Sun, 10 Aug 2008, Junio C Hamano wrote:

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

a few items

convienience

1. tieing the attributes to the file more directly will make it much 
easier to deal with them along with the file in the non-rich checkout 
(it's much easier to say README* then README .attr/README*)


consisntancy

2. putting hooks into the plumbing that can call external programs for the 
rich checkin/checkout will let all porcelains make use of the features 
without having to modify all of them independanty.

safety

3. when doing checkins/checkouts of individual files you need to be sure 
that you deal with the correct attributes at the same time (or else that 
the person is explicity requesting only a piece of it) with the attributes 
closely associated with the file this is much easier to do (this is 
another aspect of the convienience in #1 above)

4. if the configuration of what helper to use changes from one revision to 
another the plumbing (which is already looking at the tree object for both 
revisions) is in a better position to detect and alert then the porcelains

David Lang