On Thu, 26 Oct 2006, Josef Weidendorfer wrote: > On Thursday 26 October 2006 00:20, Junio C Hamano wrote: > > Heh, I spoke too fast. > > > > "git log origin..master" > > > > If you do not have none of .git/origin > > Really? I thought refs are always looked up in ".git/refs" only? 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html