david@lang.hm writes:
my initial thoughts were to have git do all it's normal work and hook
into git at the point where it's writing the file out (where today it
chooses between writing the data to a file on disk, pipeing to stdout,
or pipeing to a pager) by adding the option to pipe into a different
program that would deal with the permission stuff. this program would
only have to write the file and set the permissions, it wouldn't have
to know anything about git other then where to find the permissions it
needs to know.
it sounds like you are suggesting that the hook be much earlier in the
process,...
Well, you misread me or what I said was confusing or both. I
was suggesting totally opposite. Let git do all its normal
work, and then call your hook to munge the work tree in any way
you want.
On Sun, 16 Sep 2007, Junio C Hamano wrote:
david@lang.hm writes:
quoted
my initial thoughts were to have git do all it's normal work and hook
into git at the point where it's writing the file out (where today it
chooses between writing the data to a file on disk, pipeing to stdout,
or pipeing to a pager) by adding the option to pipe into a different
program that would deal with the permission stuff. this program would
only have to write the file and set the permissions, it wouldn't have
to know anything about git other then where to find the permissions it
needs to know.
it sounds like you are suggesting that the hook be much earlier in the
process,...
Well, you misread me or what I said was confusing or both. I
was suggesting totally opposite. Let git do all its normal
work, and then call your hook to munge the work tree in any way
you want.
I think he was replying to me, not you. I was suggesting that git stop at
the index, and let him take care of deciding how the index relates to the
work tree. That is, he'd get called instead of check_updates() in
unpack-trees. (And we might have to funnel more code paths through this
function, so that checkout-index does what read-tree -m would do, wrt
changes to the filesystem).
-Daniel
*This .sig left intentionally blank*
On Sun, 16 Sep 2007, Junio C Hamano wrote:
david@lang.hm writes:
quoted
my initial thoughts were to have git do all it's normal work and hook
into git at the point where it's writing the file out (where today it
chooses between writing the data to a file on disk, pipeing to stdout,
or pipeing to a pager) by adding the option to pipe into a different
program that would deal with the permission stuff. this program would
only have to write the file and set the permissions, it wouldn't have
to know anything about git other then where to find the permissions it
needs to know.
it sounds like you are suggesting that the hook be much earlier in the
process,...
Well, you misread me or what I said was confusing or both. I
was suggesting totally opposite. Let git do all its normal
work, and then call your hook to munge the work tree in any way
you want.
so you are saying, have git write everything out as-is and then call a
program afterwords to do things? essentially a post-checkout hook?
such a hook is useful in many situations, and would allow for the workflow
where you have /etc, /etc.git, and write scripts to move things back and
forth between them.
so I do think that this is a capability that would be useful to git
overall.
however, for the specific use-case of maintaining /etc I don't think that
it's as good as having a hook at write time.
David Lang