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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Mon, 13 Jan 2020, Junio C Hamano 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.

Nice!

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

This has been discussed on the list before this past September, but I
think the discussion has stalled after v2 was sent, most likely due to my
suggestions asking for more, I hate to admit:

	https://lore.kernel.org/git/20190907234413.1591-1-wh109@yahoo.com/

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

I understand. There is definitely a non-negligible cost involved whenever
switching from one flow that works to another that might not yet work as
well. I had the same hiccups when switching the Git garden shears over to
`--rebase-merges` (it was worth it because the result is so much faster on
Windows, of course).

Having said that, if you ever find yourself wanting Just One Feature in
`--rebase-merges` that would make it worthwhile for you to think about
switching your patch-based workflow to a `rebase -ir`-based one, please
let me know, and I will try my best to accommodate.

Ciao,
Dscho