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

Johannes Sixt [off-list ref] writes:

Jason Holden schrieb:
...

quoted

 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?