Hi Junio, On Mon, Jan 13, 2020 at 2:07 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Junio C Hamano <gitster@xxxxxxxxx> 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...
