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

[Jeff King <peff@peff.net>]

On Sat, Jun 29, 2019 at 11:18:15PM -0600, Edmundo Carmona Antoranz wrote:

> Rebuash allows us to do squash/rebase without having to resort
> to use rebase.
> 
> Consider the case where we have feature branches with merges in history:
> 
> Rx: revisions in main branch
> Fx: Revisions in feature branch
> Mx: Merge revisions (some of them with conflicts)
> 
> ------------
> 	R1---R2---R3---R4---R5---R6---R7
> 	 \         \              \
> 	  F1---F2---M1---F3---F4---M2---F5
> ------------
> 
> If on M1 there were conflicts, it's more than likely that if we tried to
> cherry-pick R1..F2 on top of R7, we will have to deal with a conflict. But that
> conflict has already been taken care of on M1. So, in order to leverage that
> work that has already been done, instead of looking back, we look forward.
> 
> 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?

If I set up that scenario like so:

  git init repo
  cd repo

  commit() {
    for i in "$@"; do echo $i >file && git add file && git commit -m $i; done
  }

  commit R1 R2 R3
  git checkout -b feature HEAD~2
  commit F1 F2
  git merge master
  commit M1
  git checkout master
  commit R4 R5 R6
  git checkout feature
  commit F3 F4
  git merge master
  commit M2 F5
  git checkout master
  commit R7

and then do:

  git merge --squash feature

I get the same merge that rebuash is doing (with R6 as the merge base,
so we see F5 and R7 conflicting with each other). And then when I finish
it with "git commit", the result is a linear strand with M3 at the tip
(and its commit message is even auto-populated with information from the
squashed commits).

-Peff