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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 24, 2007, 21:07 UTC
Message-ID: <7vejgnai1z.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1190662396.6078.63.camel@beauty>

"Josh England" <jjengla@sandia.gov> writes:

Show 7 quoted lines

> ...  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?

Because I find it would be surprising if the following commands behave differently:

	$ git cat-file blob otherbranch:path.c >path.c
        $ git show otherbranch:path.c >path.c
        $ git diff -R otherbranch path.c | git apply
        $ git checkout otherbranch path.c

These are all talking about various ways to _edit_ working tree files, and not about switching between revisions.

That's why I said I found that what the second sentence from your original description implied ("the hook gets old and new commit object name" which means we are talking about switching between revisions) was sensible, but it needs to be stressed a bit.

If you want to spacial case

        $ git checkout otherbranch path.c

it raises another issue. Which commit should supply the "extended attribute description" for path.c? Should it be taken from the current commit (aka HEAD), otherbranch, or the index?