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

From: Josh England <jjengla@sandia.gov>
Date: Sep 24, 2007, 17:58 UTC
Message-ID: <1190656680.6078.26.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 22 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?
> 
> Why does the hook run every time git-bisect suggests the next
> revision to try?

Its being run since git-bisect calls git-checkout internally, but since the 'git-checkout $branch' could potentially update the working tree it may be desirable to have the hook run. Since one stated purpose of the hook is maintain repository validity or update metadata, running the hook at this time may be the right thing to do.

> Why does the hook run when rebase starts its work?

I think this case is actually desirable. If the rebase changes some aspects of the working dir that the hook cares about (eg: metadata), then the hook will be able handle the situation correctly. Not running the hook for a rebase operation could result in the working dir being left in an inconsistent state.

-JE