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

From: Derrick Stolee <stolee@gmail.com>
Date: Jul 2, 2019, 11:37 UTC
Message-ID: <2cece7ff-49af-0cae-7cb8-7cc1821be1ca@gmail.com>
In-Reply-To: <xmqq36jp7gd8.fsf@gitster-ct.c.googlers.com>

On 7/1/2019 2:35 PM, Junio C Hamano wrote:

Show 25 quoted lines

> 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
>>> ------------
>>>
>>> At this point, all differences between M3 and R7 are the changes related to the
>>> feature branch, so we can run git reset --soft from M3 to R7 to put all those
>>> differeces in index, and then we create single revision that is both
>>> squashed/rebased for our feature branch.
>>
>> So if I understand correctly, our goal is:
>>
>>   R1--R2--...--R7--R8
>>
>> where R8 has the same tree as M3?
>>
>> Wouldn't doing "git merge --squash" do the same thing?
> 
> Yup, from Edmundo's description, I agree that they are equivalent,
> modulo the merge direction.

[snip]

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

Thanks,
-Stolee