{"id":102485,"date":"2019-05-09T07:00:00","date_gmt":"2019-05-09T14:00:00","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/oldnewthing\/?p=102485"},"modified":"2020-07-02T07:31:49","modified_gmt":"2020-07-02T14:31:49","slug":"20190509-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190509-00\/?p=102485","title":{"rendered":"Mundane git commit-tree tricks, Part 4: Changing a squash to a merge"},"content":{"rendered":"

Suppose you performed a git merge --squash<\/code>, and then later realized that you meant it to be a true merge rather than a squash merge.<\/p>\n

In diagrams, suppose you have this:<\/p>\n

\u00a0<\/div>\n
\u00a0<\/div>\n\n\n\n\n\n
A<\/td>\n\u2190<\/td>\nM1<\/td>\n\u2190 \u2190 \u2190<\/td>\nM2<\/td>\n <\/td>\nmaster<\/td>\n<\/tr>\n
 <\/td>\n\u2196\ufe0e<\/td>\n <\/td>\n <\/td>\n <\/td>\n\u22f0<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nF1<\/td>\n\u2190<\/td>\nF2<\/td>\n <\/td>\n <\/td>\n <\/td>\nfeature<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/p>\n

You then realize that you should have accepted the feature branch as a true merge rather than a squash. What can you do?<\/p>\n

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.<\/p>\n

Much faster is simply to create the commit you want and reset to it.<\/p>\n

git commit-tree HEAD^{tree} -p HEAD~ -p F2 -m comment\r\n<\/pre>\n
Note<\/b>: If using the Windows CMD<\/code> command prompt, you need to type<\/p>\n
git commit-tree HEAD^^{tree} -p HEAD~ -p F2 -m comment\r\n<\/pre>\n
for reasons discussed earlier.<\/p>\n
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.<\/p>\n\n\n\n\n\n
A<\/td>\n\u2190<\/td>\nM1<\/td>\n\u2190 \u2190 \u2190<\/td>\n*<\/td>\n <\/td>\nmaster<\/td>\n<\/tr>\n
 <\/td>\n\u2196\ufe0e<\/td>\n <\/td>\n <\/td>\n <\/td>\n\u2199\ufe0e<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\nF1<\/td>\n\u2190<\/td>\nF2<\/td>\n <\/td>\n <\/td>\n <\/td>\nfeature<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The result of the git commit-tree<\/code> command is a hash printed to stdout. You can git reset<\/code> to that hash to make that the branch head.<\/p>\n
\n