Re: [PATCH] submodule: Port resolve_relative_url from shell to C

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 13.01.2016 um 23:47 schrieb Stefan Beller:
> On Wed, Jan 13, 2016 at 2:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Stefan Beller <sbeller@google.com> writes:
>>
>>> Later on we want to deprecate the `git submodule init` command and make
>>> it implicit in other submodule commands.
>>
>> I doubt there is a concensus for "deprecate" part to warrant the use
>> of "we want" here.  I tend to think that the latter half of the
>> sentence is uncontroversial, i.e. it is a good idea to make other
>> "submodule" subcommands internally call it when it makes sense, and
>> also make knobs available to other commands like "clone" and
>> possibly "checkout" so that the users do not have to do the
>> "submodule init" as a separate step, though.
>
> Maybe I need to rethink my strategy here and deliver a patch series
> which includes a complete port of `submodule init`, and maybe even
> options in checkout (and clone) to run `submodule init`. That way the
> immediate benefit would be clear on why the series is a good idea.

I think that makes lots of sense. It looks to me like clone already
has that option (as --recurse-submodules must init the submodules),
but it might make sense to add such an option to checkout to init
(and then also update) all newly appearing submodules (just like
"git submodule update" has the --init option for the same purpose).

> The current wording is mostly arguing to Jens, how to do the submodule
> groups thing later on, but skipping the immediate steps.

I really believe that in the future a lot of users will hop on to the
automatically-init-and-update-submodules train once we have it (and I
think users of the groups feature want to be on that train by default).

But I also believe we'll have to support the old school init-manually
and update-when-I-want-to use cases for a very long time, as lots of
work flows are built around that.