Re: Git Submodule Problem - Bug?

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 07.12.2011 09:21, schrieb Manuel Koller:
>> How about this:
>>
>> The user issues 'git submodule add foo' and we discover that there is
>> already a local clone under the name foo. Git then asks something like
>> this
>>
>>        Error when adding: There is already a local submodule under the
>>        name 'foo'.
>>
>>        You can either rename the submodule to be added to a different
>>        name or manually remove the local clone underneath
>>        .git/modules/foo. If you want to remove the local clone please
>>        quit now.
>>
>>        We strongly suggest that you give each submodule a unique name.
>>        Note: This name is independent from the path it is bound to.
>>
>>        What do you want me to do ([r]ename it, [Q]uit) ?
>>
>> When the user chooses 'rename' git will prompt for a new name.
>>
>> If we are going to support the remove use case with add we additionally
>> need some logic to deal with it during update (which is not supported
>> yet AFAIK). But we probably need this support anyway since between
>> removal and adding a new submodule under the same can be a long time.
>> If users switch between such ancient history and the new history we
>> would have the same conflict.
>>is_submodule_modified()
>> We could of course just error out and tell the user that he has to give
>> the submodule an uniqe name. If the user does not do so leave it to him
>> to deal with the situation manually.
>>
>> What do you think?
>>
>> Cheers Heiko
> 
> Prompt to choose another name would be fine I guess - but it solves
> the problem only if the submodule has been initialized already. There
> could be a submodule of the same name in another branch, which I
> haven't checked out yet, for example. The user would have to be forced
> choose a unique name for every submodule.

Which seems pretty much impossible in a distributed system ...

> Anyway, it seems impossible to handle a name clash automatically,
> since there are good reasons to have different urls for the same
> submodule.> Having read the thread linked by Junio, the only way out
> seems to be a kind of url rewrite scheme and using the url as name.
> Doesn't it solve all the problems?
> 
> - the url is more or less unique (there are problems now if we have to
> different submodules at the same path, which is much more likely to
> happen than a different repository at the same url some time in the
> future)
> - after a change of the submodule's url, we can still check out old
> commits in a comfortable way
> - we could have the same submodule at different paths, but downloaded only once
> - the user is not forced to do anything, but the .gitmodule config can
> still be overruled if necessary

Hmm, using the URL has the downside that when one URL is just a fork of
the other we might have most of the repo duplicated in the .git/modules
directory ... but if it solves the problem of having a totally different
submodule cloned into the same path it might be worth it.