On Thu, Jan 14, 2016 at 12:50 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote:
> Am 13.01.2016 um 23:47 schrieb Stefan Beller:
>>
>> On Wed, Jan 13, 2016 at 2:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>>
>>> Stefan Beller <sbeller@xxxxxxxxxx> 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 next series I'll send out will replace the shell part of `git
submodule init`
with a small wrapper for `git submodule--helper init` which will then have
the functionality to initialize submodules. I'll break that C code in a way
that we'll end up having a function like:
void init_submodule(const char *path);
After that is donw, I'll try to call this from all the places which currently
do setup a child process for init or `update --init`.
>
>> 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).
Rereading old mail I wonder if we had a miss understanding on the groups
feature or rather the automatically-init-submodules feature.
As far as I understand initializing git submodules, you can do it multiple times
without hurting yourself, i.e. an implementation of update could look like
update()
{
auto-init-subs = { }
if groups selected:
auto-init-subs = {subs selected by groups}
foreach uninitialized submodule:
if submodule has set auto-init (in superprojects .gitmodule I'd guess)
auto-init-subs += {that submodule}
if auto-init-subs not empty:
git submodule init <auto-init-subs>
update-as-we-know-it
}
and then multiple calls to update() would not hurt.
That way we would not need to add any logic to the init sub command as my
first patch series had. There it was more like:
update()
{
if groups selected:
git submodule init --groups # have the logic inside of init
update-as-we-know-it
}
I think I'll redo the groups patch series as the former now.
>
> 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.
Sure, the "submodule init" command is not going away. I just want to have
an easy way to access it from within C code, hence the rewrite effort.
Thanks,
Stefan
--
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