Re: Dropping core.worktree and GIT_WORK_TREE support (was Re: limiting relationship of git dir and worktree)

From: Jeff King <peff@peff.net>
To: Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Karl Chen <quarl@cs.berkeley.edu>
Subject: Re: Dropping core.worktree and GIT_WORK_TREE support (was Re: limiting relationship of git dir and worktree)
Date: Tue, 26 Aug 2008 20:49:24 -0400	[thread overview]
Message-ID: <20080827004924.GA8204@coredump.intra.peff.net> (raw)
In-Reply-To: <48B3B256.6010609@fastmail.fm>

[resend: urgh, I somehow missed the git-list when replying, so it is
cc'd here]

On Tue, Aug 26, 2008 at 09:35:50AM +0200, Michael J Gruber wrote:

> "Typical" developers track source code in the proper sense (somewhere in
> $HOME); on local file systems; mostly on machines where they have root
> access, or least can get extra accounts (for gitosis) or a port for "git
> daemon" etc; they collaborate with peers for whom basically the same
> assumptions apply.
> 
> Now think of a user say in academics, who tracks "source code" for
> scientific papers (somewhere in $HOME) but also needs to track, e.g.,
> central web pages or other "sources" where he has partial write access
> but can't have ".git" in place (and shouldn't change ownership &

Actually, I do all of those things, and I don't use the work-tree config
variable or command line options at all. :)

I think the general advice with things like web access is "don't just
dump your git stuff into a production area; instead, build and/or
install from your git work tree into your production area". Because
things like merges _can_ leave your files in a broken state.

But I do recognize that there are some special circumstances where that
isn't possible, and you are willing to accept the tradeoff. E.g., if the
checkout is extremely large and you can't afford another copy, if you
have clueless collaborators who can't understand a build procedure.

And even though I expect those cases to be the exception, it seems a
shame for git not to support split git-dir/work-tree setups because we
really are 99% there. This code has been the source of a number of
problems.

I think what is really needed is somebody to look carefully at the git
startup sequence and figure out a sane set of rules for the order of:

  - looking at env variables
  - looking at config
  - figuring out GIT_DIR and GIT_WORK_TREE
  - chdir'ing to top level of work tree if necessary

Because we obviously have some corner cases where very confusing things
are happening.

This is on my long term todo list, but my git time is very short at
least for the next few months. I think it would be great if somebody
else wanted to take the lead on this, and I would be happy to give
pointers about some of the corner cases we have already seen.

-Peff