On 6/30/2011 8:49 AM, Junio C Hamano wrote: > Eric Raible <raible@xxxxxxxxxxx> writes: > >> The following sequence sets up a trivial repo that uses "gitdir:": >> >> $ git init gitdir-test >> $ cd gitdir-test >> $ mv .git real-git-dir >> $ echo "gitdir: real-git-dir" > .git >> $ git status >> >> Fine so far. But git-status shows that "real-git-dir" is untracked: >> >> $ git status -sb >> ## Initial commit on master >> ?? real-git-dir/ >> >> Which strikes one as a bit inconsistent (since other pars of git-status >> knows to look in real-git-dir to find the index). >> >> Sorry - no time to investigate. > > You could even have a real git dir of some completely unrelated repository > in your working tree, it will get reported as untracked, and you would > probably not want to track its contents, either (or you might want to if > you are trying to be funny, I dunno). > > So I do not see there is anything to investigate. What you observed looks > perfectly expected to me, except for the "mv .git real-git-dir" bit that > makes a situation that confuses yourself (but not git). > . The fact that the repo is stored in .git is an implementation detail - and one which git-status knows about (in the normal case). In the gidir: case one part of git status understands the details (after all - it reads real-git-dir/index) while another part doesn't (after all - it show the actual repo as a normal directory). Sure, git-real-dir could be added to git-real-dir/info/exclude. But by that logic we could insist on adding .git to .git/info/exclude. The argument about an unrelated repo in the working tree is irrelevant - .git wouldn't point to it, so there's nothings special about it. But it's obviously not a big deal either way and I'm gonna drop it. -- 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