Yes and no.
The "iterate over all refs" code only ever looks in the "refs"
subdirectory, so when you _list_ refs, they won't ever be shown unless
they are there. That affects a lot of programs (like "git ls-remote").
Also, a symlink-ref has to point into "refs/" or it is considered invalid.
But, there are two extra rules:
- ".git/HEAD" is obviously special, and will show up separately even for
things like "git ls-remote", so even processes that _list_ things will
show it.
- when you do a named lookup, stuff directly in ".git" will take
precedence over EVERYTHING, even if it is never listed. So for example,
if you have a branch named HEAD in .git/refs/heads/HEAD, it doesn't
matter. Your ".git/HEAD" will still be looked up first.
Similarly, other "special heads", like ORIG_HEAD or MERGE_HEAD will be
looked up in .git, even though they will never be listed by anything.
So the "refs/" requirement is a real requirement for a "true ref", but it
is still overruled by the rule that we have special refs in $GIT_DIR that
always take precedence.
This also means, for example, that you can always give the "full" refname
for lookup, ie
git-rev-parse refs/heads/master
works, because that's the "full path" from the ".git" subdirectory. If we
only ever looked things up inside "refs", you'd have to use
"heads/master".
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
