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

From: Phil Hord <hordp@cisco.com>
Date: May 31, 2011, 22:04 UTC
Message-ID: <4DE565DF.7050207@cisco.com>
In-Reply-To: <4DE5561C.3010200@xiplink.com>

On 05/31/2011 04:57 PM, Marc Branchaud wrote:

Show 10 quoted lines

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

>  - 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?

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

Show 5 quoted lines

> 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?

Phil