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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 15, 2020, 18:14 UTC
Message-ID: <xmqqftggk2oi.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.2001151458100.46@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

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

Nice indeed---I forgot to say more-or-less there, though ;-)

It is quite an achievement to make it practical to rebuild the maint..pu chain, which would involve 1000+ commits, while allowing to edit only a fraction of them.

	[ellided] observation that tips of the branches that were
	rewritten in order to rebase the named tip that contains
	them were left stale

> This has been discussed on the list before this past September, but I
> think the discussion has stalled after v2 was sent,...

That's OK.  One step at a time ;-)

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

Another thing I noticed was that we may want to attempt to recreate an evil merge and then stop to ask confirmation. The "rebase -ri" I did to sanity-check my revert for example failed to bring in the change made in the existing evil merge when trying to recreate the merge of the dl/merge-autostash topic into master..pu chain and silently created a fails-to-build-from-the-source tree instead.