Re: git-branch --print-current
- From
Jeff King <peff@peff.net>
- Date
- Jan 5, 2009, 05:50 UTC
- Message-ID
- <20090105055010.GA13189@coredump.intra.peff.net>
- In-Reply-To
- <7vsknys8y1.fsf@gitster.siamese.dyndns.org>
On Sun, Jan 04, 2009 at 07:55:34PM -0800, Junio C Hamano wrote:
Show 15 quoted lines
> > 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