On 7/1/2019 2:35 PM, Junio C Hamano wrote: > 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. [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
