git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Jun 30, 2019, 06:53 UTC
Message-ID
<20190630065358.GB31264@sigill.intra.peff.net>
In-Reply-To
<20190630051816.8814-1-eantoranz@gmail.com>
On Sat, Jun 29, 2019 at 11:18:15PM -0600, Edmundo Carmona Antoranz wrote:
Show 32 quoted lines
> 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
Previous: Edmundo Carmona AntoranzNext: Edmundo Carmona Antoranz
Message 4 of 13 in “rebuash - squash/rebase in a single step”
  1. 1/2 rebuash - squash/rebase in a single stepEdmundo Carmona Antoranz, Jun 30, 2019
  2. 2/2 rebuash - support for statusEdmundo Carmona Antoranz, Jun 30, 2019
  3. Edmundo Carmona AntoranzJun 30, 2019
  4. Jeff KingJun 30, 2019
  5. Edmundo Carmona AntoranzJun 30, 2019
  6. Jeff KingJun 30, 2019
  7. Edmundo Carmona AntoranzJul 1, 2019
  8. Junio C HamanoJul 1, 2019
  9. Edmundo Carmona AntoranzJul 1, 2019
  10. Junio C HamanoJul 1, 2019
  11. Derrick StoleeJul 2, 2019
  12. Junio C HamanoJul 2, 2019
  13. Johannes SixtJul 2, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.