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

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

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.

That affects two things, though.  Who becomes the first parent is
obviously swapped, but equally importantly, the merge conflicts are
presented as if you are merging from the upstream, taking assortment
of random changes into a stale codebase with slight modification.
Swapping the direction would present the merge much better in that
it let you pretend as if you started from the up-to-date upstream
and replayed your own changes in the topic, and because you are by
definition more familiar with your own changes, during conflict
resolution, you would understand the output from "git diff HEAD"
much better than the case where you merge upstream into your topic.

But "rebase the feature branch on updated upstream and then merge
the result, optionally squashing all of them into one big ball of
wax" *could* be a lot more useful feature, serving as poor-man's
imitation of "git imerge", *but* only if the final squashing is made
optional (that at the same time means that sometimes the M3 merge
can be unmanageably messy and stepwise rebase may make it
manageable).  

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.