Show 34 quoted lines
>> 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