On Tue, Jun 04, 2013 at 06:57:34PM -0400, Phil Hord wrote: > On Tue, Jun 4, 2013 at 8:48 AM, John Keeping <john@xxxxxxxxxxxxx> wrote: > > The problem is that sometimes you do want to adjust the path and > > sometimes you don't. Reading git-submodule(1), it says: > > > > This may be either an absolute URL, or (if it begins with ./ or > > ../), the location relative to the superproject’s origin > > repository. > > [snip] > > If the superproject doesn’t have an origin configured the > > superproject is its own authoritative upstream and the current > > working directory is used instead. > > > > So I think it's quite reasonable to have a server layout that looks like > > this: > > > > project > > |- libs > > | |- libA > > | `- libB > > |- core.git > > > > and with only core.git on your local system do: > > > > cd core/libs > > git submodule add ../libs/libB > > > > expecting that to point to libB. But if we adjust the path then the > > user has to do: > > > > git submodule add ../../libs/libB > > > > However, it is also perfectly reasonable to have no remote configured > > and the library next to the repository itself. In which case we do want > > to specify the additional "../" so that shell completion works in the > > natural way. > > In submodule add, the leading '../' prefix on the repository url has > always meant that the url is relative to the url of the current repo. > The given repo-url is precisely what ends up in .gitmodules' > submodule.$name.url. It works this way whether there is a remote > configured or not. > > It does seem like we need to be cautious around this change. > > > The only way I can see to resolve the ambiguity is to die when we hit > > this particular case. This should be acceptable because people > > shouldn't be adding new submodules anywhere near as often as they > > perform other submodule operations and it doesn't affect absolute URLs. > > I don't think I like that. But I don't know if I like anything I > dreamed up, either. I've decided that I will make it die (unless anyone comes up with an obviously correct solution before I get around to sending the reroll) because it's a lot easier to loosen that in the future than to change it if we get the behaviour wrong now. I don't want to hold every other subcommand hostage to this one case. -- 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