From: Jeff King <peff@peff.net>
Date: Mon, 05 Jan 2009 05:50:10 GMT
Subject: Re: git-branch --print-current
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:

> > 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