Re: [PATCH] post-checkout hook, and related docs and tests

["Josh England" <jjengla@sandia.gov>]

On Mon, 2007-09-24 at 11:34 -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
> 
> >> What's the _semantics_ you are trying to achieve?
> >
> > I'd like to get a hook that runs whenever the working dir gets
> > updated.  The 'git-checkout otherbranch path.c' case should
> > run it also, so I view that as a bug.
> 
> I think that _is_ INSANE.  Do you run the hook for these then?
> 
> 	$ edit path.c
>         $ git-cat-file otherbranch:path.c >path.c
> 
> Why "git checkout otherbranch path.c" should be any different?

It is different because the file is being updated through the 'git
checkout' interface.  The user is not copying the file over by hand,
he/she is asking git to do it for them via 'git checkout'.  Granted, the
branch (and HEAD) does not change for this operation, but that shouldn't
matter.  It is somewhat in line with the principle of 'least-surprise':
if the hook runs for 'git checkout otherbranch', but not 'git checkout
otherbranch path.c', this could cause confusion and distress to the
user.  IMO, it is a 'checkout' so the post-checkout hook should run.
Why is that so insane?  

Look at it from the perspective of the intended use of this hook.  I'm
trying to use this hook to keep working dir metadata (ownership/perms)
in a consistent state.  When I do a 'git checkout otherbranch', the hook
runs, updating perms as needed, and all is well.  As is, if I 'git
checkout otherbranch path.c', the file is created with the default
umask, the hook is not run, and path.c potentially (likely) has
incorrect perms.  The working dir is now in an inconsistent state and
the worst part is that the next commit will propagate the faulty
metadata for that file.

-JE