[PATCH v3] submodule: add 'deinit' command

[PATCH v3] submodule: add 'deinit' command

With "git submodule init" the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to "git
submodule update". But currently there is no easy way he could tell git he
does not care about a submodule anymore and wants to get rid of his local
work tree (except he knows a lot about submodule internals and removes the
"submodule.$name.url" setting from .git/config together with the work tree
himself).

Help those users by providing a 'deinit' command. This removes the whole
submodule.<name> section from .git/config either for the given
submodule(s) (or for all those which have been initialized if '.' is
given). Fail if the current work tree contains modifications unless
forced. Complain when for a submodule given on the command line the url
setting can't be found in .git/config, but nonetheless don't fail.

Add tests and link the man pages of "git submodule deinit" and "git rm"
to assist the user in deciding whether removing or unregistering the
submodule is the right thing to do for him.

Changes since v2 are:
- deinit always needs an argument; if the user wants to deinit all initialized
submodules he can use "." (and we tell him that when failing without any
arguments).
- We also remove the work tree of the submodule. When it contains local changes
(tested with "git rm -n") this fails unless forced.

+deinit::
+ Unregister the given submodules, i.e. remove the whole
+ `submodule.$name` section from .git/config together with their work
+ tree. Further calls to `git submodule update`, `git submodule foreach`
+ and `git submodule sync` will skip any unregistered submodules until
+ they are initialized again, so use this command if you don't want to
+ have a local checkout of the submodule in your work tree anymore. If
+ you really want to remove a submodule from the repository and commit
+ that use linkgit:git-rm[1] instead.
++
+If `--force` is specified, the submodule's work tree will be removed even if
+it contains local modifications.
+
update::
Update the registered submodules, i.e. clone missing submodules and
checkout the commit specified in the index of the containing repository.
@@ -213,8 +227,10 @@ OPTIONS

Do we want to make sure that $sm_path/.git is a gitfile here? I do
not think it matters that much, but the user may have local commits
that he has not pushed out, in which case it would be nicer to give
a way to preserve them.

> + mkdir "$sm_path"

Also can these rm -rf or mkdir fail, and what would we want to do
when they do?

I think it is preferrable to run "config --remove-section"
regardless, but we may want to tell the user what happened (i.e. the
submodule has been unregistered as far as Git is concerned, but the
worktree may have some cruft we couldn't remove).