Re: [RFC/PATCH 1/2] rebuash - squash/rebase in a single step

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

Derrick Stolee <stolee@gmail.com> writes:

> On 7/1/2019 2:35 PM, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>> 
>>>> First, we create a (temporary) merge commit of both branches (M3)
>>>>
>>>> ------------
>>>> 	R1---R2---R3---R4---R5---R6---R7---M3
>>>> 	 \         \              \       /
>>>> 	  F1---F2---M1---F3---F4---M2---F5
>>>> ------------
>>>>
> ...
>> If M3 merge is always easier to manage than incremental stepwise
>> rebase of the topic, then doing the "git merge --reverse-squash"
>> would be a saner interface and also conceptually simpler.
>
> I agree that this would be a better way to expose this behavior,
> and likely the implementation could be very clean.

What I was sort-of hoping to get comments on was actually something
else.

Would there be cases where the merge M3 gets unmanageably complex
even if rebasing the feature commits one by one is relatively simple
(and how often would that happen)?  "merge --squash" would not work
well (and extending the command to merge in a different direction
would not help) in such a situation, but "rebase -i" would work
much better (and "imerge" would, too).