`git-rev-parse master` not referred to by any ref?

Any idea how I got into this situation?:

	git$ git rev-parse master
	warning: refname 'master' is ambiguous.
	407c0c87e15b3cf60347f4fc0bcdb4d239de4163
	~/local/git$ git for-each-ref | grep master
	32ebe844c689d6e13e9875a0feefedca8dc1c6eb commit refs/heads/master
	e413074f1293e907d94af99330f0dd632a78b01f commit refs/remotes/linux-nfs/master
	0058a33a8eb5a8bfcfc5f5e769a2517cff4b73f1 commit refs/remotes/origin/master
	git$ git for-each-ref | grep 407c0
	git$ 

--b.

On Sun, Aug 26, 2007 at 09:45:21AM -0400, J. Bruce Fields wrote:

Any idea how I got into this situation?:

	git$ git rev-parse master
	warning: refname 'master' is ambiguous.
	407c0c87e15b3cf60347f4fc0bcdb4d239de4163
	~/local/git$ git for-each-ref | grep master
	32ebe844c689d6e13e9875a0feefedca8dc1c6eb commit refs/heads/master
	e413074f1293e907d94af99330f0dd632a78b01f commit refs/remotes/linux-nfs/master
	0058a33a8eb5a8bfcfc5f5e769a2517cff4b73f1 commit refs/remotes/origin/master
	git$ git for-each-ref | grep 407c0
	git$ 

Oops, found it:

	git$ cat .git/master
	407c0c87e15b3cf60347f4fc0bcdb4d239de4163

--b.

On Sun, Aug 26, 2007 at 09:52:51AM -0400, J. Bruce Fields wrote:

On Sun, Aug 26, 2007 at 09:45:21AM -0400, J. Bruce Fields wrote:

quoted

Any idea how I got into this situation?:

	git$ git rev-parse master
	warning: refname 'master' is ambiguous.
	407c0c87e15b3cf60347f4fc0bcdb4d239de4163
	~/local/git$ git for-each-ref | grep master
	32ebe844c689d6e13e9875a0feefedca8dc1c6eb commit refs/heads/master
	e413074f1293e907d94af99330f0dd632a78b01f commit refs/remotes/linux-nfs/master
	0058a33a8eb5a8bfcfc5f5e769a2517cff4b73f1 commit refs/remotes/origin/master
	git$ git for-each-ref | grep 407c0
	git$ 

Oops, found it:

	git$ cat .git/master
	407c0c87e15b3cf60347f4fc0bcdb4d239de4163

(Somebody on irc pointed out that

	git update-ref master 407c0c87e15b3cf60347f4fc0bcdb4d239de4163

The file's dated a couple weeks ago, so I don't remember, but I can
easily imagine that I could have typed that assuming it'd update
.git/refs/heads/master.  OK!)

--b.

"J. Bruce Fields" [off-list ref] writes:

quoted

Oops, found it:

	git$ cat .git/master
	407c0c87e15b3cf60347f4fc0bcdb4d239de4163

It _might_ make it safer to refuse creating anything outside
refs/ if the name does not contain or ends with "HEAD" (or
perhaps names that have chars outside "[_A-Z]"), but that would
restrict future tools that might want to have HEAD-like files,
so I am a bit hesitant.

OTOH, a random file under .git/ does not count as a ref for the
purposes of fsck/prune, so it may make sense to teach 
check_ref_format() about the same set of "special" names that
can appear directly under .git without being in refs/ hierarchy
(currently I think only "HEAD" and possibly "ORIG_HEAD" are in
that set).

BTW, git-merge.sh and git-reset.sh should use "git update-ref ORIG_HEAD"
instead of doing it by hand using "echo >$GIT_DIR/ORIG_HEAD".

Also, I *think* objects that are only reachable via ORIG_HEAD
are not considered as reachable by fsck/prune --- we probably
would want to fix this.

Junio C Hamano [off-list ref] wrote:

Also, I *think* objects that are only reachable via ORIG_HEAD
are not considered as reachable by fsck/prune --- we probably
would want to fix this.

Probably.  But most users also have reflog enabled on HEAD in the
repository if they were to also have ORIG_HEAD there.  In such a
case ORIG_HEAD is usually HEAD@{1}, which is considered reachable
by fsck/prune/repack.

-- 
Shawn.

On Sun, Aug 26, 2007 at 02:26:28PM -0700, Junio C Hamano wrote:

It _might_ make it safer to refuse creating anything outside
refs/ if the name does not contain or ends with "HEAD" (or
perhaps names that have chars outside "[_A-Z]"), but that would
restrict future tools that might want to have HEAD-like files,
so I am a bit hesitant.

Sure.

I would have recovered faster if I'd known had a simple way to get a
list of all the refs that git-rev-parse finds.  Is there an easy way?  I
assume "find .git -name .." will miss packed refs.  Both git-show-ref
and git-for-each-ref seem to ignore top-level references.

Maybe the "refname 'master' is ambiguous" warning could be modified to
list the choices?  I don't know if that would be overkill.

--b.