Re: en/rebase-backend (was Re: "rebase -ri" (was Re: Problems with ra/rebase-i-more-options - should we revert it?))

> Hi Junio,
> 
> On Mon, Jan 13, 2020 at 2:07 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > Junio C Hamano <gitster@pobox.com> writes:
> > >
> > >> I will push out what I wish to be able to tag as the final [*1*]
> > >> shortly but without actually tagging, so that it can get a bit wider
> > >> exposure than just the usual "Gitster tested locally and then did
> > >> let Travis try them" testing.
> > >
> > > I haven't heard from any failure report so (taking no news as good
> > > news) I'll cut the final today based on what is already on the
> > > public repositories everywhere.
> >
> > By the way, as one of the methods to double check that my result of
> > reverting the merge made sense, I ran "git rebase -ri v2.24.0 pu"
> > and excised the merge and the problematic topic out of the todo
> > list.  With the rerere database populated beforehand, it was more or
> > less a painless exercise (except for one topic, en/rebase-backend,
> > which is one of the topics that was queued forking 'master' after
> > the topic got merged *and* actually depended on what the topic did)
> > and after about 1700+ steps (which did not take more than 20
> > minutes, including the time spent for the manual rebasing of
> > en/rebase-backend topic) I got the same tree for 'pu' I pushed out
> > last night.
> 
> I wonder if I should have been the one fixing up the en/rebase-backend topic...
> 
> Also, with the new release and the review comments Phillip posted on
> the en/rebase-backend series, would you rather see me address those as
> additional patches on top of en/rebase-backend, or should we kick that
> topic out of next and have me send a full re-roll?  I'm not sure
> what'd be better and I don't mind going either direction...