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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]