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

Jens Lehmann [off-list ref] writes:

Am 02.06.2011 19:14, schrieb Junio C Hamano:

quoted

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.