"Stephen R. van den Berg" [off-list ref] 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).
On Sun, 10 Aug 2008, Junio C Hamano wrote:
quoted
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
david@lang.hm wrote:
On Sun, 10 Aug 2008, Junio C Hamano wrote:
quoted
* Define a specific leading path, say ".attrs" the hierarchy to store the
attributes information. Attributes to a file README and t/Makefile
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*)
I have to agree that from a practical standpoint for the user, having
the file and the attribute tree right next to each other in the tree is
a lot easier to manage.
So even though setting up a shadow attribute tree is cleaner because it
doesn't need some kind of magic extension, it tends to clutter the
management in the flat-file checkout case.
--
Sincerely,
Stephen R. van den Berg.
"Beware: In C++, your friends can see your privates!"