Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html