Am 25.11.2015 um 02:32 schrieb Stefan Beller:
This is also available at https://github.com/stefanbeller/git/tree/submodule-groups
It applies on top of the submodule-parallel-patch series I sent a few minutes ago.
Consider having a real large software project in Git with each component
in a submodule (such as an operating system, Android, Debian, Fedora,
no toy OS such as https://github.com/gittup/gittup as that doesn't quite
demonstrate the scale of the problem).
If you have lots of submodules, you probably don't need all of them at once,
but you have functional units. Some submodules are absolutely required,
some are optional and only for very specific purposes.
This patch series adds meaning to a "groups" field in the .gitmodules file.
So you could have a .gitmodules file such as:
[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?
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 ...
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.
# 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.
# 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.
--
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