Re: git ate my home directory :-(

From: Jeff King <peff@peff.net>
Date: Mar 26, 2013, 20:08 UTC
Message-ID: <20130326200851.GA22080@sigill.intra.peff.net>
In-Reply-To: <7vfvzit439.fsf@alter.siamese.dyndns.org>

On Tue, Mar 26, 2013 at 11:20:58AM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> When you are in ~/mail/subdir, because GIT_DIR alone does not give
> you to specify where the root-level of the working tree is, you had
> to "cd .." before running "GIT_DIR=~/git/mail.git git ...".  By
> setting GIT_WORK_TREE to point at ~/mail once, you can freely chdir
> around inside subdirectories of ~/mail without losing sight of where
> the root-level is, and if your ~/git/mail.git is tied to a single
> working tree (and that is true in this example, it is always ~/mail),
> you can even set core.worktree in ~/git/mail.git/config.

Yeah, I did not talk about moving around to multiple working trees with the same GIT_DIR. I have done that, but I do not know of a workflow where it is a good practice, and not just a one-off hack.

Show 7 quoted lines

> > We could do so now, as long as we provide an escape hatch (and I think
> > spelling that hatch as GIT_WORK_TREE=. is probably sane, but I am open
> > to other suggestions).
> 
> If we were to do so, GIT_WORK_TREE=. would be the most sensible, but
> I do not think it is worth breaking.  Why do these people set GIT_DIR
> without setting GIT_WORK_TREE in the first place?

I don't think there is a good reason. The argument, as I see it, is mainly that doing so can be confusing and destructive, and there is not a big benefit to allowing it.

I am not sure I am convinced it is worth the breakage, either. Curious as to what the code would look like, I made a straw-man series, which will follow. Note that I am not suggesting we do this, but still merely thinking about the idea.

Notably, at the end of the series a number of tests fail. A few of them are testing the GIT_DIR behavior explicitly (I fixed up t1510, but did not hunt down all of the spots), but a few of them are legitimate breakages in scripts. For example, difftool is broken because it sets GIT_DIR. That gives us an indication of what kinds of breakages we would see in real-world third-party scripts.

Show 6 quoted lines

> > The problem is not with "clean", which just happens to be a destructive
> > command, but rather with the notion of what the git tree is when you
> > provide GIT_DIR.
> 
> Yes, "git add ." would happily add random cruft to your index, which
> is equally bad.

Eh, I would say it is bad, but not equally bad to removing your entire home directory. ;)

-Peff