Re: [PATCH 2/2] Don't clean any untracked submodule's .git dir by default in git-clean

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 30, 2009, 07:34 UTC
Message-ID: <7vljna9nuz.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4A49B36D.2080103@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 11 quoted lines

> Jason Holden schrieb:
> ...
>>  If
>> we run git-clean on the mainline branch, when we have a submodule that only
>> exists on a local branch, the entire .git directory of the untracked
>> submodule will get deleted, possibly losing any un-pushed local changes to
>> the submodule.
>
> This is not about "mainline" and "local branch"; it is about switching
> from one branch that tracks the submodule to another one that doesn't
> track it.

I do not think it is even about that.

If you have an old-style nested git work tree, i.e. you have an independent git repository in some subdirectory of a work tree of a git work tree, you will have exactly the same issue. There is no need for any submodule to get involved.

For example, I have a clone of git.git repository at Meta/ and have the 'todo' branch checked out, so that I can say "Meta/Make", "Meta/Dothem", etc. In such a set-up, if you do not have Meta/ in .gitignore (or even if you do, if you said "git clean -f -x -d"), you will lose that directory (and arguably that is by design).

I think protecting users from mistakes is a very good idea, but I see at least two small problems with the patch. For brevity I'll name the "not a submodule in the HEAD commit of the superproject" directory "Meta/" in the following.

 (1) Protecting Meta/.git is not goot enough. If it were, and if this is
     only about submodules, then you can use the "gitdir:" facility to
     relocate Meta/.git directory to somewhere under superproject's .git
     and be done with it.

     You _must_ protect the checked out files, their uncommitted contents
     and untracked but unignored files.  After all, Meta/ is a valid git
     repository in its own right.  Noticing that "rm -r" is about to
     remove Meta/.git after it has already touched many other files in
     Meta/ is one recursion level too late.

 (2) Naming the option to force removal "-m" is wrong; this is not about
     submodule at all.  Can we use double-force "-f -f", perhaps?