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

From: Josh England <jjengla@sandia.gov>
Date: Sep 24, 2007, 17:14 UTC
Message-ID: <1190654052.6078.14.camel@beauty>
In-Reply-To: <7vzlzfh7xd.fsf@gitster.siamese.dyndns.org>

On Fri, 2007-09-21 at 17:15 -0700, Junio C Hamano wrote:

Show 19 quoted lines

> "root" <root@sandia.gov> 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.