On Mon, 2007-09-24 at 11:34 -0700, Junio C Hamano wrote: > "Josh England" <jjengla@xxxxxxxxxx> 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 - 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
