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