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