On Sun, 16 Sep 2007, Junio C Hamano wrote:

quoted text
> 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.

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*
-
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