Re: [PATCH] Convert emailing part of hooks--update to hooks--post-receive

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 24 Mar 2007, Andy Parkins wrote:
> 
> Oh dear; I had no idea that packed refs made the ref file itself 
> disappear.

Everybody should do

	git pack-refs --all --prune

occasionally to see this. In fact, I think we should probably make that 
part of "git gc" (which currently doesn't pack branches at all, just tags, 
since it omits the "--all").

> Would
> 
>  git-rev-parse $refname
> 
> Be a better way of getting the revision?

That's always the correct way to get a revision, although you should use

	git-rev-parse --verify "$refname"^0

to make sure that you get a commit (of course, if you don't want a 
commit, but any random ref-SHA1, remove the "^0" from the end!).

HOWEVER. "git-rev-parse" will take any arbitrary SHA1-expression, which 
may or may not be what you want. If you actually also want to verify that 
it's strictly a branch name (or other ref-name), rather than just a random 
SHA1 expression, you should do

	git show-ref [--verify] refname

where the "--verify" again enables strict checking. HOWEVER, it will not 
check that it's a commit, so if you need the resulting SHA1 to be of a 
specific type, you need to do that separately.

Side note: those two "--verify" calls do two different kinds of strict 
checking, because "show-ref" and "rev-parse" are different things. In 
"git-rev-parse" it checks that the argument is exactly *one* SHA1 value, 
and not some flag or a SHA1 range. Because "git rev-parse" can take a lot 
of different input formats. In contrast, in "git show-ref", the stricter 
checking enabled by "--verify" will just force it to not do any "pattern" 
for the ref, but it wants an *exact* refname.

		Linus