Jeff King <peff@xxxxxxxx> 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.
