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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 24, 2007, 16:12 UTC
Message-ID: <Pine.LNX.4.64.0703240858370.6730@woody.linux-foundation.org>
In-Reply-To: <200703241550.05590.andyparkins@gmail.com>

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").

Show 5 quoted lines

> 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