Re: git ate my home directory :-(

[Jeff King <peff@peff.net>]

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

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