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

Philippe Blain [off-list ref] writes:

quoted

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

quoted

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:

quoted

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