Re: [PATCH] submodule add: improve message when resolving a relative url fails

[Marc Branchaud <marcnarc@xiplink.com>]

On 11-05-31 06:04 PM, Phil Hord wrote:
> On 05/31/2011 04:57 PM, Marc Branchaud wrote:
>> Thanks for the cogent explanation & patch.  I think the message could be
>> improved a bit:
>>
>> 	Cannot resolve "../sub" relative to this repository's "origin"
>> 	remote: The remote's URL is not set in .git/config
>>
>> However, overall I think this is a pretty fragile way to handle relative
>> paths.  Consider:
>>
>>  - The super-repo must be a clone in order for this to work at all.
> 
> Yes, but that constraint (mostly) makes sense to me.  But if 'git
> submodule add' did not initialize .git/config, this constraint could be
> dropped.
> 
>>  - The super-repo cannot be checked out on a detached HEAD.
> 
> Why do you think that?  I just tried this and it worked fine for me.  I
> can't think of a reason for it to fail.

Whoops, right.  I was confusing a different error with the fact that "git
symbolic-ref HEAD" fails on a detached HEAD.  The code defaults to "origin"
as the remote name in this case (perhaps that's not strictly the right thing
to do, but I'm sure this isn't the only part of git that assumes there's a
remote called "origin").

>>  - The current code rewrites the URL so that any relative path is either
>>    rejected or munged into an absolute remote URL.
> 
> I don't see the URL getting munged away from being relative.  Can you
> point to an example?

I reached this conclusion because if I go into my clone of git.git and do

	git submodule add ../MyThing

where ../MyThing is a regular git repo, I get

Cloning into MyThing...
fatal: The remote end hung up unexpectedly
Clone of 'git://git.kernel.org/pub/scm/git/MyThing' into submodule path
'MyThing' failed

So it seemed the relative URL became an absolute URL.

Looking more closely at a working example, I can see that (as you show below)
the URL in the super-repo's .gitmodules file retains the relative path, but
the submodule's remote.origin.url is an absolute path.

In any case, "submodule add" isn't doing what I expected: make my local
MyThing repo a submodule of my git.git clone.

>> It seems to me that this feature will only work in a fairly narrow set of
>> circumstances, and even when it does work it's likely to do something
>> unexpected (think of a super-repo with several remotes).
> 
> I use it this way with several remotes. 
> 
>> Back when Junio accepted the original patch, he said "If you maintain and
>> serve a set related projects you need to give the users a single URL (per
>> where the user is and how to reach the server)."  I'm not sure I understand
>> that:  Why would the users be adding their own submodules to the
>> superproject?  Wouldn't the superproject define the submodules in for them?
> I am a user.  I admin a super-project for other users.  This project
> lives at three remotes, remotes/public, remotes/shared and remotes/build. 
> 
> I add a new submodule to the superproject like this:
> 
>    mkdir sub && cd sub && git init
>    cd ..
>    git submodule add ../sub sub
> 
> This results in the new submodule being inserted into my .gitmodules
> file and my .git/config:
> 
>    tail -3 .gitmodules
>    [submodule "sub"]
>        path = sub
>        url = ../sub
> 
>    tail -2 .git/config
>    [submodule "sub"]
>        url = public:git/sub
> 
> I do have to make sure to push my submodule to the correct location on
> each remote before pushing my new .gitmodules.
> 
> But the exact same commands work for me if I do this first and then do
> 'git submodule add ../sub' afterwards. 
> 
> So, I don't understand your objections.  Do you understand my use case
> any better?

It's not so much an objection as confusion over how "submodule add" works.

I believe your case works smoothly only because in your super-project you're
careful to make sure you have checked out a branch that remotely tracks a
something in remotes/public.  If you checked out a branch that tracks a
different remote you'd get different results.  This seems fragile to me.

When you tried the detached-HEAD scenario, did you get URLs for
"public:git/sub" or "origin:git/sub"?  Does "origin" just happen to be the
remote you want to use in any case?

My fundamental point is that "git submodule add" seems to do confusing things
with relative paths.  Maybe all that's needed is to clarify the
documentation.  I'll post a patch.

		M.