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

[John Keeping <john@keeping.me.uk>]

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