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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 13, 2020, 22:03 UTC
Message-ID: <xmqqpnfnj9p3.fsf_-_@gitster-ct.c.googlers.com>
In-Reply-To: <xmqqy2ubjkeo.fsf@gitster-ct.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 10 quoted lines

> 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.