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

[Junio C Hamano <gitster@pobox.com>]

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.

One thing I noticed that "rebase -ri" could be taught to handle
better was that the side branches that were merged to the final
result did not get relabeled.  Those merges that appear on the first
parent chain leading to 'pu' call themselves as "Merge branch 'blah'"
and many of them (i.e. the ones that forked before the merge of the
topic getting excised from the mainline) did just merge the tip of
the named branch without touching the commits on the side branch,
but some branches did have to be rebased, but their tips did not get
updated (only the tentative rewritten/<topic> labels were pointing
at the updated tip during the rebase, which are of course discarded
after we are done).

But other than that, it was quite nice.

It is less transparent (at least to me) and probably less efficient
than the current workflow to rebuild 'pu' for a few times every day
("less efficient" is primarily because the established workflow is
quite optimized to the way I work), so it is not likely for me to
switch to "rebase -ri" any time soon.  But it makes me feel safe to
know that there is another tool I can use to double-check the result
of everyday workflow.

Thanks.