Hi Glen,

Le 2021-11-15 à 14:03, Glen Choo a écrit :

Thanks so much Philippe, your responses are very thoughtful.

Philippe Blain [off-list ref] writes:

quoted

quoted

* `git branch --recurse-submodules topic` should create the branch
    `topic` in each of the repositories.

I guess for some workflow this would be the good, but for others you might
not need to create submodule branches for each new superproject branch you
create.  I think I pointed that out before; I don't necessarily think that
creating branches in all submodules should *not* be the default behaviour,
but I think that it should be configurable. I mean that if I have 'submodule.recurse'
set to true, I would not like 'git branch topic' to create a 'topic' branch
in each submodule. So I wish I'll be able to add 'branch.recurseSubmodules = false'
to my config (or something similar) to have more granularity in behaviour.

Yes, as we discussed earlier, this behavior may not be desirable for
different workflows. I've come to suspect that the branching behavior
that I proposed should be the default, but I'm ambivalent on being able
to opt out of the branching.

In favor of letting users opt out: I'd imagine that behavior might be
disruptive to users who make frequent changes on the submodule and may
not appreciate having two sets of branch names (one from the
superproject and one from the submodule's remotes). I'm not clear on
whether or not this is disruptive primarily because it is a breaking
change, or if this just an objectively bad fit for what these users
want.

In favor of not letting users opt out: exposing fewer switches to users
makes it easier for them to get a good user experience. Instead of
giving users the ability to build-your-own UX, maintaining a small
configuration surface makes configuration easy and puts the onus back on
Git (or me, really :P) to make sure that the UX really works well for
all users, instead of opting out and saying "oh the user has
branches.recurseSubmodules=false, so I'll choose not to support them".
I think this stance is good from a product excellence perspective, but
it's an obvious risk.

A way forward might be:

* mitigate the breaking changes by flagging this with
   feature.experimental
* test this behavior with real users (aka internal) and iterate from
   there

Does that make sense? I'd like to make sure I'm not missing something
very big here.

It does, but I think that we can still build a flexible product without
compromising UI/UX :)

quoted

Also, I assume the new behaviour would carry over to 'git checkout -b' and
'git switch -c' ?

quoted

* `git switch --recurse-submodules topic` should checkout the branch
    `topic` in each of the repositories

Nit: I guess you also include 'git checkout --r topic' here also ?

Yes and yes (I believe --r refers to --recurse-submodules?).

Yes, and it works on the command-line ! ;) long options can be shortened
if unambiguous, see 'man gitcli'.