On Wed, Nov 25, 2015 at 11:18 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> 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
(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.
* 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.
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
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.
--init should not be needed as when the groups are there we automatically
init new submodules in the group set?
> 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.
>
--
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