Re: [RFC PATCH 0/5] Submodule Groups

Am 01.12.2015 um 00:54 schrieb Stefan Beller:

On Wed, Nov 25, 2015 at 11:18 AM, Jens Lehmann [off-list ref] wrote:

quoted

quoted

quoted

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?

quoted

quoted

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.

quoted

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.