{"id":104245,"date":"2020-09-21T07:00:00","date_gmt":"2020-09-21T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=104245"},"modified":"2020-09-21T09:40:47","modified_gmt":"2020-09-21T16:40:47","slug":"20200921-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20200921-00\/?p=104245","title":{"rendered":"Git commit-tree parlor tricks, Part 8: I just rebased my branch, but now I realize that I should have merged"},"content":{"rendered":"

Suppose you created a feature branch in git and made some changes. Meanwhile, the main branch has also made some changes:<\/p>\n

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

From a common ancestor commit A, we create a feature branch and make two commits, F1 and F2. Meanwhile, the master branch has received two commits M1 and M2.<\/p>\n

You decide to rebase your topic branch onto the main branch. Many merge conflicts later, you finish with this:<\/p>\n\n\n\n\n\n
A<\/td>\n\u2190<\/td>\nM1<\/td>\n\u2190<\/td>\nM2<\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\nmaster<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n\u2196\ufe0e<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\n <\/td>\nF1\u2032<\/td>\n\u2190<\/td>\nF2\u2032<\/td>\n <\/td>\nfeature<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The resulting graph is now linear, with the original commits A1, M1 and M2, followed by new commits F1\u2032 and F2\u2032.<\/p>\n

And then you realize that what you really meant to do was merge, not rebase. Is there a way to convert the rebase into a merge without having to go back and deal with all those merge conflicts again?<\/p>\n

Indeed there is.<\/p>\n

We’ve seen something very similar before, when we retroactively converted a squash to a merge<\/a>. This is pretty much the same thing: We have a final result, and we want to manufacture a merge that has the same final result.<\/p>\n

git commit-tree HEAD^{tree} -p M2 -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 M2 -p F2 -m comment\r\n<\/pre>\n
for reasons  discussed earlier<\/a>.<\/p>\n
What we did was manufacture a new commit that contains the same results as F2\u2032, but assigned it the parents M2 and F2. The first parent is the branch you want to pretend that you are merging to<\/i>, and the second parent is the branch you want to pretend that you are merging from<\/i>.<\/p>\n\n\n\n\n\n
A<\/td>\n\u2190<\/td>\nM1<\/td>\n\u2190<\/td>\nM2<\/td>\n\u2190<\/td>\nF2\u2032<\/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 output of the git commit-tree<\/code> command is a commit hash. You can now reset to that commit, and all will be forgiven.<\/p>\n
git reset --soft \u2329hash\u232a\r\n<\/pre>\n
Resetting in soft mode preserves all the changes you may have staged. Those staged changes are still valid because the starting point hasn’t changed: The commit you are resetting to has the same tree as the commit you are moving from.<\/p>\n
Bonus chatter<\/b>: If we had swapped the two parent commits, like this:<\/p>\n
git commit-tree HEAD^{tree} -p F2 -p M2 -m comment\r\n<\/pre>\n
then the result would have been<\/p>\n\n\n\n\n\n
A<\/td>\n\u2190<\/td>\nM1<\/td>\n\u2190<\/td>\nM2<\/td>\n <\/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\u2190<\/td>\nF2\u2032<\/td>\n <\/td>\nfeature<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n