On Tue, Aug 3, 2021 at 4:08 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jeff King <peff@xxxxxxxx> writes: > > > It would make sense to me to do the switch in 'next' early in the > > post-v2.33 cycle. It can cook there for a bit, but I think we have found > > that it's much more likely to see actual use once it hits 'master'. So I > > don't see a particular reason to have it sit in 'next' for a long time. > > We should get as much exposure in 'master' during the v2.34 cycle as > > possible. > > I do not mind queuing what is available today to 'next' to gain 2 > more weeks of dogfood time during the pre-release freeze. So I think I made a small mess here. Much of the second patch wasn't specific to the change of default, so I decided to split it up into a bunch of tiny documentation fixes that could be beneficial before 2.33 (https://lore.kernel.org/git/pull.1059.git.git.1628004920.gitgitgadget@xxxxxxxxx/) So, perhaps I should submit a v2 of this series which is based on that other one; then the second patch will only have the pieces specific to the change of default left. > If an > simple escape hatch that lets us say "anytime we ask ort, use > recursive instead as an emergency measure" can be added with a > trivially obvious small patch, that would be a plus. I think what you're asking for here is the `pull.twohead` config option that has existed for a while (despite its name, it affects merge, rebase, cherry-pick, and revert).
