Re: git ate my home directory :-(

From: Jeff King <peff@peff.net>
Date: Mar 26, 2013, 17:41 UTC
Message-ID: <20130326174059.GA10383@sigill.intra.peff.net>
In-Reply-To: <5151D589.2000002@nod.at>

On Tue, Mar 26, 2013 at 06:06:17PM +0100, Richard Weinberger wrote:

Show 7 quoted lines

> >We could, but that would break the existing behavior for other people
> >(and I assume you mean "when GIT_WORK_TREE is not set at all", as I
> >would think GIT_WORK_TREE=. is explicit enough).
> 
> Is there a valid use case to call git-clean with GIT_DIR set but GIT_WORK_TREE
> not (or to ."")?
> It will delete "." ;)

Yes, setting GIT_DIR but not GIT_WORK_TREE has always been a valid way to work on a repository where you do not want the working tree polluted with your .git file. It's not a common setup, but people do use it. E.g., you might keep ~/mail as a git repo, but do not want the presence of ~/mail/.git to confuse your mail tools. You can keep ~/git/mail.git as just a repository, and do "cd ~/mail && GIT_DIR=~/git/mail.git git foo" (or "git --git-dir=~git/mail.git foo").

Later, we introduced GIT_WORK_TREE (and core.worktree), which provided another way of doing the same thing (instead of the "cd", you could set GIT_WORK_TREE). For the most part, I'd expect setting core.worktree to be the simplest for such setups, as once it is set, you can just do "cd ~/git/mail.git git foo", and everything should just work.

We never deprecated the original "GIT_DIR without GIT_WORK_TREE means '.' is the implicit worktree" behavior, as nobody ever complained, and it would break existing users of the feature.

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). And in general we try to avoid such breakage without a deprecation period to give people time to fix their scripts and workflows.

> But was kinda shocked that git-clean deletes files outside my git tree.
> I'm aware of -d. But in my case it happened within a fully automated script.
> I simply thought GIT_DIR=.. git-clean -f -d does the right thing...

It did do the right thing; just not the one you expected. :)

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. Though clean is an obvious problematic command, something like "git reset --hard" could also be destructive. I don't think it makes sense to do any fix that is specific to clean. If there is a fix to be done, it should be about making the working tree lookup algorithm more obvious.

-Peff