Re: [PATCH] Clarified how "git submodule add" handles relative paths.

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 5, 2011, 18:27 UTC
Message-ID: <7vipskb0br.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4DE93B29.4030401@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 15 quoted lines

> Am 02.06.2011 19:14, schrieb Junio C Hamano:
>> I suspect that it would be a relatively easy fix if your toplevel
>> superproject is its own authoritative upstream.  Something along the line
>> of this patch, perhaps?  It is obviously untested, and we may want to
>> issue an "echo >&2 'info:...'" to tell the user what we are assuming in
>> this codepath.
>
> Maybe it is better to not automagically switch from "path is relative to
> url configured in superproject" to "path is relative to $(pwd)" depending
> on the presence or absence of a default remote in the superproject. When
> a user wants to set up his submodules relative to the superproject and
> simply did forget to configure the url of the superproject first he won't
> notice that anymore after this patch. But instead he will get a local
> submodule url only to find out later that this was not what I wanted (and
> an 'info' can easily be missed).

Sorry, I don't get this. The "how-about-this" patch was not about "automagically switch depending on ...". Absense of the remote in the superproject means that the project originates from here, iow, it is its own "origin" (that is your third use case).

I think I understand the scenario you are worried about; let me illustrate to make sure I got it right:

 1. You are starting your project that will have subproject locally. You do
    not have "origin" yet.

 2. You create a subproject "xyzzy", still locally, and add it with
    "submodule add ./xyzzy" with a relative URL.

 3. You will deploy your superproject and subproject at "git://host.xz/mine/"
    and "git://host.xz/mine/xyzzy", respectively.

 4. But because in step 2. your .git/config is already set up to point
    your local $(pwd)/xyzzy as the submodule location. This is not what
    you want and you may not notice it.

Is that the problem you are worried about? If so, I think you are solving it in a wrong way.

By not allowing a relative path, in step 2. you would entice the user to say "submodule add $(pwd)/xyzzy" (as there is no final upstream location yet), no? If the project is going to be eventually published at a different location, not just .git/config but .gitmodules also needs to be updated as part of step 3. Isn't that going backwards? If you allow the user to say "./xyzzy" in step 2., the .gitmodules entry can stay the same from the get-go.

If you think about "absense of the remote in the superproject means the project originates from here", what you are doing in step 3. is to changing the origin of these set of projects. After changing the origin of these set of projects, isn't "git submodule sync" an established way to adjust to the change? I was hoping that that would update .git/config in step 3. so you wouldn't have the problem in step 4. at all.

It is likely I am missing something in the above analysis. Please correct me.

Thanks.