Re: rebase-in-C stability for 2.20

From: Elijah Newren <newren@gmail.com>
Date: Nov 14, 2018, 00:36 UTC
Message-ID: <CABPp-BGOq2jAp79qU-XYkCv18WLBdw7huKsmBYTJcS2e_jzvFw@mail.gmail.com>
In-Reply-To: <87y39w1wc2.fsf@evledraar.gmail.com>

On Tue, Nov 13, 2018 at 1:52 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 10 quoted lines

> According to Junio's calendar we're now 2 days from 2.20-rc0. We have
> the js/rebase-autostash-detach-fix bug I reported sitting in "pu" still,
> and then this.
>
> I see we still have rebase.useBuiltin in the code as an escape hatch,
> but it's undocumented.
>
> Given that we're still finding regressions bugs in the rebase-in-C
> version should we be considering reverting 5541bd5b8f ("rebase: default
> to using the builtin rebase", 2018-08-08)?

That date feels slightly misleading; it has a commit date of Oct 11, and only merged to master less than two weeks ago. Given how big the two different rebase in C series were, I'd expect a couple small things to fall out after it hit master, which is what appears to be happening.

Show 7 quoted lines

> I love the feature, but fear that the current list of known regressions
> serve as a canary for a larger list which we'd discover if we held off
> for another major release (and would re-enable rebase.useBuiltin=true in
> master right after 2.20 is out the door).
>
> But maybe I'm being overly paranoid. What do those more familiar with
> this think?

I probably don't qualify as more familar, but giving my $0.02 anyway... I'm happy that setting rebase.useBuiltin=false by default exists an escape hatch if things don't settle down as we get closer to the release, but I'd rather wait until further into the RC cycle before going that route, personally.