Re: Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)

On Tue, Jun 04, 2013 at 06:57:34PM -0400, Phil Hord wrote:

On Tue, Jun 4, 2013 at 8:48 AM, John Keeping [off-list ref] wrote:

quoted

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.

quoted

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.