Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes:
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html