Re: [RFC/PATCH 0/5] [WAS: Submodule Groups] Labels and submodule.autoInitialize
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Jan 24, 2016, 19:38 UTC
- Message-ID
- <56A52818.8080808@web.de>
- In-Reply-To
- <1453509103-16470-1-git-send-email-sbeller@google.com>
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:
Show 16 quoted lines
> 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.
Show 6 quoted lines
> # 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?)
Show 5 quoted lines
> 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.
Show 31 quoted lines
> 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(-)
>