Subject: Re: [PATCH 0/3] submodule add: allow relative repository path even when no url is set

From: Jens Lehmann <[email-masked]>
Date: Tue, 07 Jun 2011 23:03:58 +0200

Am 06.06.2011 23:23, schrieb Marc Branchaud:
> On 11-06-06 05:00 PM, Junio C Hamano wrote:
>> I actually still have a feeling that I may be missing something from the
>> discussion.  While I do like a solution that lifts existing limitation to
>> allow workflows that were hitherto impossible, that only makes sense when
>> the newly allowed workflow makes sense and useful, and when the lifted
>> limitation was not protecting some silly mistakes from getting made.
>>
>> I _think_ our last exchange gave me a fuzzy confirmation that we are not
>> lifting a useful limitation, but I still do not know if the new workflow
>> matches the workflow Marc (who kicked off this thread) wanted to use. I
>> think it does match the set-up Phil Hord mentioned in an earlier message,
>> though.

After thinking about this issue some more I think the change is good. We
only affect relative urls and obviously don't change the case where the
url is already set in the superproject (that case stays like it is and
users like Phil seem to like it that way).

For the case where the url is not set I see two use cases: The first for
people who would like to keep their submodules local (like me and Marc):
the new behavior enables us to use a relative path too, so we are happy.
Then there are those who want to have a submodule relative to the super-
projects url: they won't get an error anymore when using a relative url
without having a default remote in the superproject. But that is easily
fixed later by doing a "submodule sync" when they recognize that fact,
just like Junio explained.

> There may still be a lingering niggle where git might do something the user
> doesn't expect.  For example, git might create a submodule out of
> git://origin/foo.git instead of the local ../foo.git.  You have to be paying
> attention to git's output to notice that difference, and I could see where a
> user might get tripped up.  But IMO improving this can be done independently
> of Jens's patches.

This behavior exists for some time and is not changed by the patches in
question. But maybe when this patch is applied and people get used to
relative paths for local submodules that might become an issue when they
run into it. But I surely won't have an upstream defined for a superproject
I want to add a local submodule too, so I doubt that.

Or am I still missing something?