Am 04.06.2013 14:48, schrieb John Keeping:
> On Tue, Jun 04, 2013 at 09:17:17PM +1000, Heiko Voigt wrote:
>> On Tue, Jun 04, 2013 at 09:10:45AM +0100, John Keeping wrote:
>>> On Tue, Jun 04, 2013 at 03:29:51PM +1000, Heiko Voigt wrote:
>>>> On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote:
>>>>>> Sorry, I should have been more specific here. I saw that you did some
>>>>>> changes to make "submodule add" do the right thing with relative paths,
>>>>>> but the following change to t7406 does not work like I believe it
>>>>>> should but instead makes the test fail:
>>>>>> -------------------8<---------------------
>>>>>> diff --git a/t/ b/t/
>>>>>> index a4ffea0..9766b9e 100755
>>>>>> --- a/t/
>>>>>> +++ b/t/
>>>>>> @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the 
>>>>>> same pa
>>>>>>  test_expect_success 'submodule add places git-dir in superprojects 
>>>>>> git-dir' '
>>>>>>         (cd super &&
>>>>>>          mkdir deeper &&
>>>>>> -        git submodule add ../submodule deeper/submodule &&
>>>>>> +        (cd deeper &&
>>>>>> +         git submodule add ../../submodule submodule
>>>>>> +        ) &&
>>>>>>          (cd deeper/submodule &&
>>>>>>           git log > ../../expected
>>>>>>          ) &&
>>>>>> -------------------8<---------------------
>>>>> Ah, ok.  I think this case is problematic because the repository
>>>>> argument is either relative to "remote.origin.url" or to the top of the
>>>>> working tree if there is no "origin" remote.  I wonder if we should just
>>>>> die when a relative path is given for the repository and we're not at
>>>>> the top of the working tree.
>>>> Why not behave as if we are at the top of the working tree for relative
>>>> paths? If there is an origin remote thats fine. If there is no origin
>>>> remote you could warn that the path used is taken relative from the root
>>>> of the superproject during add. What do you think?
>>> That's what the patch currently queued on "pu" does, which Jens wants to
>>> change, isn't it?
>> True I did not realize this when reading it the first time. But I think
>> we should still not die when in a subdirectory. After all this series is
>> trying to archive that the submodule command works in subdirectories
>> seamlessly right? So you probably want to translate a relative path
>> without "origin" remote given from a subdirectory to the superproject
>> level and use that. Then you do not have to die.
> 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.


> 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

resolve_relative_url ()
        remoteurl=$(git config "remote.$remote.url") ||
                remoteurl=$(pwd) # the repository is its own authoritative 

And this looks like a central place to handle this issue too (but I
admit I only glanced over the call sites of resolve_relative_url(),
so I might be missing something here).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to