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