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

[Glen Choo <chooglen@google.com>]

Philippe Blain <levraiphilippeblain@gmail.com> writes:

>> 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.

> 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:
 
>> * 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 :)