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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 1, 2012, 00:06 UTC
Message-ID: <7v7grbf42l.fsf@alter.siamese.dyndns.org>
In-Reply-To: <5068B329.7040302@web.de>

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

Show 17 quoted lines

>> 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.