On Fri, 2007-09-21 at 17:15 -0700, Junio C Hamano wrote: > "root" <root@xxxxxxxxxx> writes: > > > +post-checkout > > +----------- > > + > > +This hook is invoked when a `git-checkout` is run on a local repository. > > +The hook is given two parameters: the ref of the previous HEAD, and the ref of > > +the new HEAD. This hook cannot affect the outcome of `git-checkout`. > > + > > +This hook can be used to perform repository validity checks, auto-display > > +differences from the previous HEAD, or set working dir metadata properties. > > + > > People may wonder why this is not run when they do "git checkout > otherbranch path.c"; the second sentence from the above > description implies why it shouldn't, but the first sentence > probably should state it more clearly. > > 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. > Why does the hook run every time git-bisect suggests the next > revision to try? > Why does the hook run when rebase starts its work? It may be inserted in a ad place or maybe it needs some intelligence in there to know when *not* to run. > When "git pull" or "git merge" results in a fast forward, the > situation is no different from checking out a new revision. Why > doesn't the hook run in these cases? This is actually what I'd like to do. I submitted the post-merge patch some time ago to serve that purpose. Do you think they should both be rolled into a single post-checkout hook? It would seem to make sense to me. - 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
