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. 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. > The nice thing is that the two strategies can co-exist. So if it does > turn out to have any regressions, it's an easy revert to switch back, > and even post-release users can switch at runtime. We have pull.twohead, > but I don't think we have an equivalent that would impact a bare "git > merge" or "git rebase -m". Maybe it would be worth adding those as an > escape hatch?
