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

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