Re: [RFC] Branches with --recurse-submodules

Philippe Blain [off-list ref] writes:

quoted

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

Agreed. The long term result might be that submodules + branches will
always live behind its own flag (though I hope not..). One person's
flexibility is another person's complexity, so we will need a lot of
finesse in order to find the right tradeoff.

quoted

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

Ah, TIL. Thanks :)