Re: [PATCH] pull: respect submodule update configuration

From: Brandon Williams <bmwill@google.com>
Date: Aug 22, 2017, 18:55 UTC
Message-ID: <20170822185543.GA114773@google.com>
In-Reply-To: <CAGZ79kbpf-a_ZinPLuPh2Vq629=cQknuLVF-QVwOeae1ZGS2Cw@mail.gmail.com>

On 08/22, Stefan Beller wrote:

Show 50 quoted lines

> On Tue, Aug 22, 2017 at 7:50 AM, Lars Schneider
> <larsxschneider@gmail.com> wrote:
> >
> > OK. I change my scripts to use ".active" and it seems to work nicely.
> >
> > I noticed one oddity, though:
> >
> > If I clone a repo using `git clone --recursive <url>` then the local
> > Git config of the repo gets the following entry:
> >
> > [submodule]
> >         active = .
> 
> bb62e0a99f (clone: teach --recurse-submodules to optionally take a
> pathspec, 2017-03-17) makes it clear that this is intentional for
> --recurse-submodules, but doesn't exactly state that --recurse will
> behave the same. The idea here is that at clone time you can already
> give
> 
>     git clone --recurse=:(exclude)sub0 <url> <path>
> 
> and have your desired set of submodules there.
> Combined with the changes in the attr system, b0db704652
> (pathspec: allow querying for attributes, 2017-03-13)
> you could make up things like this:
> 
>   $ cat .gitattributes
>   /sub0 label0
>   /sub1
>   /sub2 label1 label2
>   /sub3 label1
>   /platform-specifc-subs/* label1 label2
> 
> and then get a clone via
> 
>     git clone --recurse=:(attr:label2). <url> <path>
> 
> for example. The labeling via the attributes allows for
> complex patterns, but a relatively easy command line, that you
> can share with coworkers.
> 
> > Is this intentional? Something in the git/git test harness seems to prevent
> > that. I was not able to write a test to replicate the issue.
> >
> > Any idea?
> 
> I do not seem to understand the perceived bug?
> The setting of submodule.active=<pathspec> seems intentional to me,
> but how would you not reproduce it? Maybe Brandon has an idea.
>

When adding '.active' we wanted it to be as flexible as possible. So you can either use a pathspec with 'submodule.active' to catch multiple submodules as being active or you can turn on/off individual submodules with 'submodule.<name>.active' (this has precedent over the more general 'submodule.active' config).

The intent was if a user supplies --recurse-submodules (I believe i removed the docs for --recursive in order to make the CLI more consistent with other commands, so --recursive is just a synonym for --recurse-submodules) then they clearly wanted all the submodules cloned and checked out. With the '.active' config the way to specify this is to make 'submodule.active = .'. In the old world every submodule would need to have its URL copied into the config. This way the config is kept cleaner as it only has a single entry added.

As stefan mentioned you can specify a value for 'submodule.active' to take as an arg to --recurse-submodules (the default being '.' or all submodules) so you can do clever things like group submodules using attributes, you can even repeat the flag to provided a more complex pathspec.

Hopefully that answers your question :D

-- 
Brandon Williams