Disclaimer: Due to my currently very limited Git time budget I only
glanced over the recent discussion and patches. If you think I missed
something already discussed, I'd be happy being pointed to the relevant
discussion so I can catch up and avoid wasting everybody's time.
Am 23.01.2016 um 01:31 schrieb Stefan Beller:
This series introduces labels which you can attach to submodules like so:
$ cat .gitmodules
[submodule "gcc"]
path = gcc
url = git://...
label = default
label = devel
[submodule "linux"]
path = linux
url = git://...
label = default
$ git submodule add --name emacs --label "editor" --label default git://...
# If upstream has submodules properly labeled, you can make use of them:
Cool. Without having looked at the code I assume you also can label
submodules yourself in .git/config (or your global config) to override
upstream's settings (or use your own labels if .gitmodules does not
contain any)?
$ git config --add submodule.autoInitialize "*default"
$ git config --add submodule.autoInitialize ":name"
$ git config --add submodule.autoInitialize "./by/path"
Ok. Though we might wanna call it submodule.autoUpdate, as initializing
it is only the prerequisite for automatically updating submodules. And
I believe automatically updating is the thing we're after here, right?
I'll try to explain why I believe we should be generous in initializing
submodules: If a submodule in one branch has a label configured to be
automatically updated and hasn't got the same label in another branch,
we still need to initialize the submodule even when we are on the latter
branch in case the user switches to the first branch, right? And the
fetch command needs to fetch submodule changes too when they happen in
a branch where this submodule is part of a label group configured to be
updated automatically, no matter what is currently found in the work
tree.
So I'd propose to:
*) Initialize every submodule present on clone or newly fetched when
the autoUpdate config is set.
*) Automatically fetch only those submodules that are changed in
a commit where they have a label configured (in the commit's
.gitmodules or locally) that is to be checked out.
*) Let "git submodule update" update only those submodules that
have an autoupdate label configured.
That will make switching between branches with different label
configurations work fine. Or am I missing something here?
And we need to teach diff and status to complain about empty work
trees and missing initialization of submodules that are to be
automatically updated too.
# The prefix * denotes a label as found in .gitmodules
# : goes before names
# path are prefixed ./ currently
# both path and names need work
Question: how do I configure all submodules to be automatically
initialized without having to give them a label? "./*"? Or just
setting the option without a specific value?
# no --init necessary, partially initializes submodules (only those which
# were specified by label, name or path)
$ git submodule update
Yup. Just like they will be fetched if they haven't been yet they
should be initialized if they haven't been yet but are configured
to be automatically updated.
# time passes, upstream may have added new submodules and we get them without
# extra commands!
$ git submodule update
# The above configuration can be given to git clone directly via:
$ git clone --init-submodule=*labelA ...
Ok. Expecially nice is the ability to also give names and paths to
"--init-submodule". (but maybe that option should be called
"--autoupdate-submodule" for the reasons stated above?)
Why?
====
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.
I'd rather like to see this as a special case of sparse checkout, as
this will be a submodule-specific solution to a more generic problem.
But as I understand configuring sparse checkout won't materialize for
quite some time, so I suspect we'll have to add labels first to make
current submodule users happy in the near future. Sparse configuration
can then re-use the infrastructure added here.
Changes to the previous version with groups:
====
* it's called labels now (it's easier to imagine to attach more than one
label to a submodule than having it in more groups)
* In .git/config we have another name, too ("submodule.autoInitialize")
* Support for more than just groups, but also names and paths are supported
(in a very rudimentary way though)
This series applies on top of sb/submodule-init, or can be found at
https://github.com/stefanbeller/git/tree/submodule-groups-v3
Thanks,
Stefan
Stefan Beller (5):
submodule init: Write submodule registration to stderr
git submodule: Teach add to label submodules
submodule-config: keep labels around
submodule update: respect submodule.autoInitialize
builtin/clone: Configure submodule.autoInitialize via --init-submodule
Documentation/git-clone.txt | 6 ++
Documentation/git-submodule.txt | 5 +-
builtin/clone.c | 40 +++++++++-
builtin/submodule--helper.c | 58 +++++++++++++-
git-submodule.sh | 14 +++-
submodule-config.c | 15 ++++
submodule-config.h | 2 +
t/t7400-submodule-basic.sh | 165 ++++++++++++++++++++++++++++++++++++++++
8 files changed, 298 insertions(+), 7 deletions(-)
--
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