Re: [RFC/PATCH 0/5] [WAS: Submodule Groups] Labels and submodule.autoInitialize

[Jens Lehmann <Jens.Lehmann@web.de>]

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(-)
>