Stupid git commit-tree tricks, Part 4: Changing a squash to a merge

Raymond Chen

Raymond

Suppose you performed a git merge --squash, and then later realized that you meant it to be a true merge rather than a squash merge.

In diagrams, suppose you have this:

AM1← ← ←M2 master
 ↖︎   
  F1F2   feature

From a starting commit A, the master branch continues with a commit M1. From that same starting commit A, a feature branch adds commits F1 and F2. Now you decide to take the feature branch into the master branch, and you resolve the merge as a squash. This means that the resulting commit M2 technically has only a single parent M1. The other alleged parent F2 is just a dotted line, indicating that it is just a figment of your imagination.

You then realize that you should have accepted the feature branch as a true merge rather than a squash. What can you do?

Naturally, you could hard reset the master branch back to M1 and redo the merge. But that means you have to redo all the merge conflicts, and that may have been quite an ordeal. And if that was a large merge, then even in the absence of conflicts, you still have a lot of files being churned in your working directory.

Much faster is simply to create the commit you want and reset to it.

git commit-tree HEAD^{tree} -p HEAD~ -p F2 -m comment

Note: If using the Windows CMD command prompt, you need to type

git commit-tree HEAD^^{tree} -p HEAD~ -p F2 -m comment

for reasons discussed earlier.

This creates a tree identical to what is currently checked in (which is the merge result), whose parents are M1 and F2. In other words, it colors in the dotted line.

AM1← ← ←* master
 ↖︎   ↙︎
  F1F2   feature

The result of the git commit-tree command is a hash printed to stdout. You can git reset to that hash to make that the branch head.

Raymond Chen
Raymond Chen

Follow Raymond   

5 Comments
Avatar
Mantas M. 2019-05-09 08:43:17
This situation came up in #git yesterday, and I would have used a different approach: git replace --graft HEAD HEAD^ F2 && git commit --amend -C HEAD (The second command was originally "git filter-branch HEAD^!", which is less ugly, but if you want the commit to be signed, you'd have to follow that up with --amend anyway...)
Avatar
Simon Clarkstone 2019-05-09 13:07:24
This week has made me more aware of ways I could be using Git that I'm not. I learnt early on in my usage of Git that once you start thinking about a Git repo as a directed graph it becomes obvious how you need to re-arrange the graph and you only need to learn which commands exist to do each step (like the from this week).Tangent: It took me a while, but I finally realised (possibly) why Raymond is so concerned about the amount of churn in the working copy (apart from these being neat Git tricks and exercises in minimalism). For readers who don't know: a large part of Windows is kept in one 300GB Git repository and MS created a special filesystem to allow a partial clone and partial working copy to appear to be a full clone and working copy.
Avatar
Alex Thiessen 2019-05-11 10:01:36
I'd do like (untested): checkout master reset --hard master^ merge feature checkout master@{1} . # resolves all conflicts add . # mark resolved merge --continue This probably leads to more build activity and SSD wear than your version, yet many devs don't care.