Re: [RFC PATCH 0/5] Submodule Groups

--cc Johannes Sixt

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

quoted

[submodule "gcc"]
         path = gcc
         url = git://...
         groups = default,devel
[submodule "linux"]
         path = linux
         url = git://...
         groups = default
[submodule "nethack"]
         path = nethack
         url = git://...
         groups = optional,games

Yup. Do you want the user to select only a single group or do you
plan to support selecting multiple groups at the same time too?

Yes you should be able to select multiple groups, such as
default+devel or alternatively default+games.

The logical OR is supported in this patch series (all submodules which are
in at least one of the specified groups,i.e. A OR B OR C ...)

quoted

and by this series you can work on an arbitrary subgroup of these
submodules such
using these commands:

     git clone --group default --group devel git://...
     # will clone the superproject and recursively
     # checkout any submodule being in at least one of the groups.

Does this automatically configure the given group in .git/config, so
that all future submodule related commands know about this choice?
Me thinks that would make sense ...

It does. Internally it does

    git config submodule.groups A,B
    git submodule update --init --groups

whereas submodule update checks if the submodule.groups
value is set and if so operates on the groups only.

quoted

     git submodule add --group default --group devel git://... ..
     # will add a submodule, adding 2 submodule
     # groups to its entry in .gitmodule

Maybe '--groups default,devel' is easier to grok? Dunno.

I guess that makes sense.

quoted

     # as support for clone we want to have:
     git config submodule.groups default
     git submodule init --groups

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.

Well if upstream changes grouping later, you could just run

    git submodule update --init --groups

and get what you want?

quoted

     # will init all submodules from the default group

     # as support for clone we want to have:
     git config submodule.groups default
     git submodule update --groups

     # will update all submodules from the default group

Any feedback welcome, specially on the design level!
(Do we want to have it stored in the .gitmodules file? Do we want to have
the groups configured in .git/config as "submodule.groups", any other way
to make it future proof and extend the groups syntax?)

Not sure what exactly you mean by "it" here ;-)

Talking about what groups a submodule belongs to, an entry in the
.gitmodules file makes the most sense to me. That way upstream can
change submodule grouping or add new submodules with group assignments
from commit to commit, and "git submodule update" will do the right
thing for the superproject commit checked out.

And I believe that the choice which group(s?) the user is interested
should be recorded in .git/config, as that is his personal setting
that shouldn't be influenced by upstream changes.

Right. I once discussed with Jonathan Nieder, who dreamed of a more
logical approach to the groups/sets of submodules. So more like set theory,
i.e. have a more complicated grammar: Get all submodules which are
in either A or B or (D AND E), but which are never in F.
So I'd imagine the groups are more like bit tags, and you can describe
a patterns you want.

I guess we want some more powerful eventually, so I asked this open ended
question there.