On Tue, Jun 04, 2013 at 06:57:34PM -0400, Phil Hord wrote:
> On Tue, Jun 4, 2013 at 8:48 AM, John Keeping <j...@keeping.me.uk> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html