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

From: Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
Date: Aug 26, 2008, 07:35 UTC
Message-ID: <48B3B256.6010609@fastmail.fm>
In-Reply-To: <7v7ia6j5q9.fsf_-_@gitster.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 25.08.2008 02:30:

> Jeff King <peff@peff.net> writes:
>

Show 5 quoted lines

>> Well, as a non-user of this feature, I certainly have no argument
>> against taking it out. Maybe the subject line will pull some other
>> people into the discussion.
> 
> Heh, if we are to do the attention-getter, let's do so more strongly ;-)

Sorry for being late to the discussion.

I think there are many use cases or environments which differ substantially from those of the "typical" developer; this implies that they differ from those of the typical git contributor, which naturally leads to a certain bias in discussions like this one.

"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 & permissions), but needs to be aware of changes and log own changes; on NFS; no extra accounts but in need of an authenticated protocol (papers in progress are private, public only when published); who collaborates with peers for whom the same assumptions apply, except most certainly for git usage...

Yes, that's me, but also many others, I would think and hope, at least increasingly so. That second scenario is one where I have to cope with how things are set up centrally, making the best possible use of git.

I would imagine that many corporate environments are basically similar, if individual employees want to use git without central support.

These remarks apply to the discussion about an authenticated protocol (some way for secure, private pull&push for users with access to $HOME and maybe cgi-bins), but also here:

I need to keep .git away from the work tree for several projects. Using --git-dir etc. leads to problems with some commands, especially git{k,-gui,-citool}. I found the most robust solution to be an alias (shell) which guesses the work tree (from core.worktree etc.) and cd's there before doing anything. This also solves the problems with diff.

I would strongly advocate for keeping the possibility of separating git-dir and work-tree, and possibly dropping the assumption that everything "foo.git" is a bare repo. There are config variables for this. The Tcl/Tk family I mentioned makes even stronger assumptions. I promise to have a look at these when I find time (oh yeah...).

Michael