"Josh England" <jjengla@xxxxxxxxxx> writes:
> ... 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?
-
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
