Re: [RFC PATCH 0/5] Submodule Groups

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

Am 01.12.2015 um 00:54 schrieb Stefan Beller:
> On Wed, Nov 25, 2015 at 11:18 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>>>
>>>> Hmm, I doubt it makes much sense to add the --group option to "git
>>>> submodule init". I'd rather init all submodules and do the group
>>>> handling only in the "git submodule update" command. That way
>>>> upstream can change grouping later without having the user to
>>>> fiddle with her configuration to make that work.
>>>
>
> Mind to elaborate a bit more here?
> The way I understand you now is to pass not --groups to init,
> but init initializes all submodules. But that is worse IMHO

Hmm, I did not mean to imply that "git init" should initialize
all submodules. Me thinks that "git clone --groups" should do
that but then only fetch and checkout those submodules the
chosen groups select. I expect "git submodule init" to be
obsolete when submodule groups (or recursive update) are used,
and that's why IMO it doesn't need a --groups option. (If the
user wants to change the groups later we might need to teach
"git submodule sync" the --groups option though)

> (In the naive way of dealing with groups in the first patch series)
> as then we open up two possibilities:
>   * a submodule which happened to be part of the repository
>     when cloning is added to a new group, which a user has
>     configured, on pulling, this is no problem, we just checkout
>     the desired version of the submodule.

That'll only work automatically when we follow my proposal to
init all those submodules present on clone, because otherwise
it won't be initialized.

>   * a submodule which was not part of the repository at the time
>     of cloning, is added to the superproject with a group the user
>     is subscribed to. This would not be checked out as it is uninitialized
>     on disk.

That's why I propose a mechanism to "auto-init" new submodules
on fetching their gitlink in the superproject. Then both your
groups proposal and my recursive update could make them appear
in the work tree on the next update/checkout. And as fetch is
part of clone, I'd expect clone to "auto-init" all submodules
referenced in gitlinks too.

> So when a change of the set of submodules as defined by groups
> occurs, that is the point in time, when we want to init/fetch/checkout
> these submodules, no?
>
>>>
>>> Well if upstream changes grouping later, you could just run
>>>
>>>       git submodule update --init --groups
>>>
>>> and get what you want?
>>
>>
>> And make life harder than necessary for our users without having
>> a reason for that?
>
> So if upstream changes groups, ideally we want to follow without much
> hassle for the user. So a plain git pull should /just work/. (I am repeating
> myself here I'd guess), we would need to react to that. if we drop the
> --groups call to init, we'd still tell the user to run
>
>       git submodule update

Sure, that's still needed until we have recursive update.

> We do not need --groups any more in a later patch as instead of
> passing in --groups we can detect for `git config submodule.groups`
> to be available or not.

Yes.

> --init should not be needed as when the groups are there we automatically
> init new submodules in the group set?

Right.

>> Except for the URL copying submodule settings
>> on init is wrong, as it sets in stone what happened to be in the
>> .gitmodules file when you ran init and doesn't allow upstream to
>> easily change defaults later. We still do that with the update
>> setting for historical reasons, but I avoided making the same
>> mistake with all the options I added later. You can override
>> these settings if you want or need to, but that shouldn't be
>> necessary by default to make life easier for our users.
>>
>