git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Philippe Blain <levraiphilippeblain@gmail.com>
Date
Nov 23, 2021, 18:36 UTC
Message-ID
<30f6ee13-8db7-e983-fb87-ef038a3487a2@gmail.com>
In-Reply-To
<kl6lr1bhtf67.fsf@chooglen-macbookpro.roam.corp.google.com>
Hi Glen,
Le 2021-11-15 à 14:03, Glen Choo a écrit :
Show 48 quoted lines
> Thanks so much Philippe, your responses are very thoughtful.
> 
> Philippe Blain <levraiphilippeblain@gmail.com> writes:
> 
>>> * `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 :)

Show 9 quoted lines
> 
>> Also, I assume the new behaviour would carry over to 'git checkout -b' and
>> 'git switch -c' ?
>>> * `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'.

Previous: Glen ChooNext: Glen Choo
Message 10 of 11 in “[RFC] Branches with --recurse-submodules”
  1. Glen ChooNov 8, 2021
  2. Glen ChooNov 10, 2021
  3. rsbecker@nexbridge.comNov 10, 2021
  4. Glen ChooNov 10, 2021
  5. rsbecker@nexbridge.comNov 10, 2021
  6. Glen ChooNov 11, 2021
  7. Philippe BlainNov 12, 2021
  8. Philippe BlainNov 12, 2021
  9. Glen ChooNov 15, 2021
  10. Philippe BlainNov 23, 2021
  11. Glen ChooNov 23, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.