On Thu, Mar 12, 2020 at 12:12 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > > On Thu, Mar 12, 2020 at 8:13 AM Emily Shaffer <emilyshaffer@xxxxxxxxxx> wrote: > >> ... > >> This broke quite a few upstream users for us today... > > One more thing I've been wondering was if we should really have said > "ok, the two known gotchas have been dealt with, so let's ship it". > It is quite likely that users may be hit by remaining differences > between the merge and apply backends that we assume to be merely > subtle and easy-to-work-around ones, and it may be prudent to use > the "let's not change the default just yet, but ask people to test > it in their workflow by advertising the configuration" patch. Good question, but there's several things to unpack here... First, note that this particular breakage would have occurred regardless of the default setting, because the problem was that they setting rebase.backend to an unrecognized value, not that we used a different backend than they were used to. Second, for the particular case of the post-commit hook that they referenced in their rationale, that item was documented near the end of the 2.25 cycle and mentioned in previous patchsets[1, 2] so I figured this case was already considered. Those two points may obscure the issue, though; your question is still valid. I think the bigger question is whether there are other unknown differences, or even known differences that are a bigger issue than we currently realize. That's hard to judge, and it may not be possible to judge until we've flipped the default. As such, it's a judgement call. I can see the judgement call going either way. A couple things to weigh in on how to go: - Making rebase.backend default to 'apply' for 2.26 is certainly the conservative option and may give us more feedback and time to iron out differences - We had multiple complaints this cycle about rebase.backend=apply merging things incorrectly with the only workaround being to use the merge backend[3,4] - The rebase-backend topic wasn't merged down to master until less than a week before -rc0. (For a variety of reasons.) A big change like this probably would have been better to merge down earlier in some cycle. To be honest, if I was maintainer, I'm not sure which direction I'd pick. If you feel safer switching the default backend to apply for this cycle and then (re-)revert it early next cycle to the merge backend, I think that's totally reasonable. [1] https://lore.kernel.org/git/pull.679.v4.git.git.1579155273.gitgitgadget@xxxxxxxxx/ [2] https://lore.kernel.org/git/CABPp-BHONuRyt8VJqRuoCF2rGYZ5EhH9KJXQZ3NO69rYwA5J3g@xxxxxxxxxxxxxx/ [3] https://lore.kernel.org/git/CABPp-BGiu2nVMQY_t-rnFR5GQUz_ipyEE8oDocKeO+h+t4Mn4A@xxxxxxxxxxxxxx/ [4] https://lore.kernel.org/git/20200108223557.GE32750@xxxxxxxxxx/
