Re: [PATCH v2 2/2] submodule add: Fail when .git/modules/<name> already exists unless forced

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@web.de> writes:

>> Good point! I will add a more detailed error message (including
>> the url of the default remote which is configured for the already
>> present submodule repo) and teach --force to skip the test and
>> resurrect that submodule repo.
>
> The message when "git submodule add" finds .git/modules/<name> is:
>
> A git directory for '<name>' is found locally with remote(s):
>   origin	<url(s) from .git/modules/<name>>
> If you want to reuse this local git directory instead of cloning again from
>   <url given on command line>
> use the '--force' option. If the local git directory is not the correct repo
> or you are unsure what this means choose another name with the '--name' option.
>
> When run with the --force option the following message is printed:
>
> Reactivating local git directory for submodule '<name>'.

Thanks, will re-queue.

The approach "submodule rm" takes when removing a project is to
treat the removed submodule as not necessary for the current commit
in the superproject, but it is considered necessary elsewhere in the
history of the superproject, and that is why we stash away the
repository in $GIT_DIR/modules of the superproject.

We may however want to think about another mode of user error where
the user runs "submodule add $path" for a wrong repository, realizes
the mistake _before_ making any commit and try to repoint the $path
to a correct repository.  The behaviour of "submodule add" in this
patch, and the behaviour of existing "submodule rm", assumes that
the user is not stupid and won't make such a mistake, but to recover,
the user may need a way to really nuke the submodule repository that
was added by the earlier misteake (which is not needed anywhere in
the history of the superproject) and $GIT_DIR/module/$name really
replaced with the updated one.

I don't know how important to support a recovery procedure from such
mistakes, though.