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