Re: Inconsistent results from git rev-parse --show-toplevel

From: Jeff King <peff@peff.net>
Date: Feb 14, 2020, 06:36 UTC
Message-ID: <20200214063649.GD605125@coredump.intra.peff.net>
In-Reply-To: <TU4PR8401MB111777B793EA9C3D5336CE26F9040@TU4PR8401MB1117.NAMPRD84.PROD.OUTLOOK.COM>

On Thu, Jan 30, 2020 at 09:59:31PM +0000, Crabtree, Andrew wrote:

Show 12 quoted lines

> > > But the bigger thing, I think, is: who is setting GIT_DIR but not
> > > setting GIT_WORK_TREE to match? Because IMHO that's the situation
> > > that is causing the confusion.
> 
> > but it fails a test in t5601 around git-clone. 
> 
> Thanks jeff.  It looks like this might have been tried previously and
> abandoned?  I'm pretty far out of my league here in terms of how
> things are supposed to operate and any history around the previous
> attempts at making it work.
> [...]
> commit d95138e695d99d32dcad528a2a7974f434c51e79

Yeah, the commit you found was doing exactly the thing I suggested. IMHO the right path forward is to actually fix the weirdness in git-clone. It would be a backwards incompatibility, but a pretty obscure one. I think we're likely to help more people than hurt by being able to handle $GIT_WORK_TREE consistently. At least that's my gut feeling.

I guess one way to fix it without breaking compatibility would be for us to set $GIT_WORK_TREE alongside $GIT_DIR, but _also_ set a special $GIT_CLONE_NO_RESPECT_WORK_TREE variable that would instruct it that the caller isn't trying to do trigger the special $GIT_WORK_TREE behavior.

But we'd have to carry that hack around forever, which doesn't excite me.

-Peff