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

> Am 04.06.2013 14:48, schrieb John Keeping:
> > 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.
> 
> Exactly.
> 
> > The only way I can see to resolve the ambiguity is to die when we hit
> > this particular case.
> 
> Hmm, I'm not so sure about that. Don't the first three lines in
> resolve_relative_url() show how to distinguish between these two
> cases?
>
> resolve_relative_url ()
> {
> 	remote=$(get_default_remote)
> 	remoteurl=$(git config "remote.$remote.url") ||
> 		remoteurl=$(pwd) # the repository is its own authoritative upstream
> ...