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).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
