On Sun, Jan 04, 2009 at 07:55:34PM -0800, Junio C Hamano wrote:
> > I agree, its nuts to be there. But this also does show up in 1.6.1.
> > What's odd is the output of rev-parse --git-dir is wrong:
> >
> > $ cd .git/refs
> > $ git rev-parse --git-dir
> > .
> >
> > Its *not* ".", its "..", I'm *in* the directory. This throws off
> > a lot of the other operations we do in __git_ps1, like detecting
> > the repository state by checking MERGE_HEAD or rebase-apply.
> >
> > I think we should fix rev-parse --git-dir if we can, not the bash
> > completion code.
>
> Sigh, yeah, that is what I thought would be happening.
I took a quick look at this. I think there is something fundamentally
wrong with the logic for reporting relative git-dir. It basically ends
up doing something like (this is in setup_git_directory_gently, but the
value is just printed directly in rev-parse):
while (1) {
if (is_git_dir(".")) {
setenv("GIT_DIR", ".");
break;
}
chdir("..");
}
So yes, it's true at the end of that loop that we the git dir _is_ ".",
but that isn't suitable for telling any other processes who didn't
follow the chdir with us.
The quick fix is for rev-parse to turn that into an absolute path. I
don't know if that breaks any callers.
A better fix is probably for setup_git_directory to not require changing
the directory (or to chdir back to the original at the end, and set the
GIT_DIR in a properly relative manner).
-Peff
--
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
