Re: git ate my home directory :-(

[Jeff King <peff@peff.net>]

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

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

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

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