Re: [RFC PATCH 2/2] branch: add --recurse-submodules option for branch creation

From: Glen Choo <chooglen@google.com>
Date: Sep 22, 2021, 17:24 UTC
Message-ID: <kl6lsfxw34m5.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <084caed9-5854-9fe2-8476-b5325ddac52c@gmail.com>

Philippe Blain <levraiphilippeblain@gmail.com> writes:

Show 7 quoted lines

>> git-branch will create the "topic" branch in the superproject and all
>> submodules.
>> 
>> recurse_submodules is only supported for creating a branch. git-branch
>
> small nit: we usually don't refer to the dashed form of commands anymore: 'git branch'
> would be preferable.

Ah, thanks! I really appreciate the style pointers.

Show 10 quoted lines

> However, I think that for this new feature, I would prefer *also* having
> a new config 'branch.recurseSubmodules' (or similar) that would allow
> more granular control than 'submodule.recurse', which influences several
> commands. Personnally I have 'submodule.recurse' set to true in my '~/.gitconfig',
> because I want the submodules working trees to be updated when I use 'git checkout'
> to change branches, 'git grep' to search the working tree, etc., but I usually
> do not *work* on the submodules in my project and I would not like new branches
> being created in them every time I create a new branch in the superproject.
> In other words, 'branch.recurseSubmodules=false' would have higher priority
> than 'submodule.recurse=true'.

That's a good point. This behavior of git branch --recurse-submodules has the potential to directly conflict with established workflows. Opting out via 'branch.recurseSubmodules seems reasonable and I think we definitely want to give users that fine-grained control. I wonder if we should take this even further - perhaps --recurse-submodules is too disruptive to be controlled by the config value as checkout, fetch, pull, etc.

Perhaps submodule.recurse should be more fine-grained, so we can ship good defaults for different workflows e.g. options that map to the current true/false behavior and another option that includes branching (I wish I could give these names, but I have no clue what to name them).

> Most tests for submodules are usually in separate test files. I don't think
> this is a set-in-stone rule, but if more tests are coming in the future, maybe
> a new test file t????-branch-submodule.sh would be appropriate ? Just a small suggestion.

I think that's a good call. It also looks like the tests in this file are somewhat old, so it would be nice to start on a clean slate :)

>> In this patchset, branching works slightly differently between the
>> superproject and submodule (skip ahead for specifics). There are two
>> very obvious alternatives that can address this:

Show 5 quoted lines

>> * A: only implement --recurse-submodules behavior after we are able to
>>   eliminate any kind of dependence on the_repository/global state that
>>   shouldn't be shared.
>> * B: implement --recurse-submodules as child processes, which won't be
>>   bothered by global state.

Your comments on the UX make a lot of sense, and I'll think about that more carefully. Let me know if you also have thoughts on the implementation itself, particular on in-process vs child process :)