Re: [PATCH] submodule init: warn about falling back to a local path

[Stefan Beller <sbeller@google.com>]

On Fri, Feb 24, 2017 at 12:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> When a submodule is initialized, the config variable 'submodule.<name>.url'
>> is set depending on the value of the same variable in the .gitmodules
>> file. When the URL indicates to be relative, then the url is computed
>> relative to its default remote. The default remote cannot be determined
>> accurately in all cases, such that it falls back to 'origin'.
>>
>> The 'origin' remote may not exist, though. In that case we give up looking
>> for a suitable remote and we'll just assume it to be a local relative path.
>
> IOW we keep the .url to be relative, the same as the original one we
> took from .gitmodules?

Well that is one way to say that. Another way is:
If we cannot construct a URL based on the given relative URL, we
demote the relative URL to be a relative PATH and resolve that instead.

>  That sounds like a sensible thing to do and
> I agree it makes sense to warn when it happens.

ok.

>
>> @@ -118,18 +122,22 @@ too (and can also report changes to a submodule's work tree).
>>
>>  init [--] [<path>...]::
>>       Initialize the submodules recorded in the index (which were
>> -     added and committed elsewhere) by copying submodule
>> -     names and urls from .gitmodules to .git/config.
>> -     Optional <path> arguments limit which submodules will be initialized.
>> -     It will also copy the value of `submodule.$name.update` into
>> -     .git/config.
>> -     The key used in .git/config is `submodule.$name.url`.
>> -     This command does not alter existing information in .git/config.
>> -     You can then customize the submodule clone URLs in .git/config
>> -     for your local setup and proceed to `git submodule update`;
>> -     you can also just use `git submodule update --init` without
>> -     the explicit 'init' step if you do not intend to customize
>> -     any submodule locations.
>> +     added and committed elsewhere) by copying `submodule.$name.url`
>> +     from .gitmodules to .git/config, resolving relative urls to be
>> +     relative to the default remote.
>
> I read this as "copying..., resolving relative to the default remote
> (if exists)."  A reader would wonder what happens if the default
> remote does not exist---don't we want to describe what happens in
> that case, like, "recording . (the current repository) as the
> upstream" or something?

eh, a better approach is s/copying/<something else>/
We will resolve the relative URL no matter what. It's just that
we may end up with an absolute path instead of an absolute URL.

>
>> ++
>> +Optional <path> arguments limit which submodules will be initialized.
>> +If no path is specified all submodules are initialized.
>
> Perhaps s/ all submodules/,&/?

ok

Will reroll, once I have found a better wording.