{"id":104302,"date":"2020-09-28T07:00:00","date_gmt":"2020-09-28T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=104302"},"modified":"2020-09-27T22:01:28","modified_gmt":"2020-09-28T05:01:28","slug":"20200928-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20200928-00\/?p=104302","title":{"rendered":"git commit-tree parlor tricks, Part 9: How can I bulk-revert an entire repo to an earlier commit?"},"content":{"rendered":"

Suppose you’ve made a bunch of commits to a branch, and then you decide that you want to roll back the entire repo to an earlier commit. Just pretend the last dozen commits never happened. The branch policy prevents force-pushes, so you will have to make a new commit that effectively reverts a large number of commits.<\/p>\n

\u00a0<\/div>\n
\u00a0<\/div>\n\n\n\n
A<\/td>\n\u2190<\/td>\nM1<\/td>\n\u2190<\/td>\nM2<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

We start with some commit A, and there have been some commits M1 and M2 on top of it. What’s the easiest way to do a bulk revert back to A?<\/p>\n

You might think you could merge commit A with the -s theirs<\/code> option, but that doesn’t work because commit A is already in the history of the branch, so the merge does nothing.<\/p>\n

Another thing you could try is to git checkout A -- .<\/code> from the root of the repo, saying that you want to take every single file from commit t<\/code> and put it into the current tree. This mostly works, except that any files added after commit A will not be deleted. The git checkout A -- .<\/code> will update all the files that were present in A, but any files added in M1 and M2 will not be deleted.<\/p>\n

My old standby is git commit-tree<\/code>. In this case, we want to create a commit on top of HEAD<\/code> with the contents of an earlier commit.<\/p>\n

git commit-tree A^{tree} -p HEAD -m \"Bulk revert back to A\"\r\n<\/pre>\n
Note<\/b>: If using the Windows cmd<\/code> command prompt, you need to type<\/p>\n
git commit-tree A^^{tree} -p HEAD -m \"Bulk revert back to A\"\r\n<\/pre>\n
for reasons  discussed earlier<\/a>.<\/p>\n
The git commit-tree<\/code> command will spit out a hash, which you can fast-forward to.<\/p>\n
If you want to express this as a merge, you could say<\/p>\n
git commit-tree A^{tree} -p HEAD -p A -m \"Bulk revert back to A\"\r\n<\/pre>\n
This generates a merge commit that would not normally be found in nature: Merging a commit that you already have.<\/p>\n\n\n\n\n\n
A<\/td>\n\u2190<\/td>\nM1<\/td>\n\u2190<\/td>\nM2<\/td>\n\u2190<\/td>\nM3<\/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>\n\u2190 \u2190<\/td>\n\u2190<\/td>\n\u2190 \u2190<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
We have manufactured a commit M3 which represents a merge of its own ancestor commit A.\u00b9<\/p>\n
Now, there are plenty of other ways to accomplish the same thing. I like commit-tree<\/code> because it directly creates exactly the commit I want, and it does so without affecting the index or working tree.<\/p>\n
On the other hand, it doesn’t give you a chance to inspect and possibly alter the result before committing. Then again, maybe that’s not a problem. After you fast-forward to the manually-created commit, you can make whatever additional changes you like and either make a new commit on top, or amend the previous commit.<\/p>\n
But maybe you prefer to have the commit staged. You can do that by reading the desired target into the index and asking for the working tree to be updated to match. Make sure your index and working tree are clean by doing a git status<\/code> and verifying that it says “Nothing to commit, working tree clean.” And then do this:<\/p>\n
git read-tree -mu A\r\n<\/pre>\n
This makes the index and working tree match the tree from commit A. (If your working tree and index are not clean before doing this, the results will be merged in, which will probably be a mess.) You can now inspect the results, make additional changes, whatever, before you commit.<\/p>\n
If you want to commit this as a “not found in nature” merge, you’ll still have to do some git commit-tree<\/code> magic:<\/p>\n
git write-tree\r\n<\/pre>\n
This will print a tree hash. Feed that hash to the next line:<\/p>\n
git commit-tree \u2329hash\u232a -p HEAD -p A -m \"Bulk revert back to A\"\r\n<\/pre>\n
This will print a commit hash. Fast-forward to that commit to complete the artificial merge.<\/p>\n
Okay, this is all great, but what if you didn’t want to revert the entire repo, but just a part of it? We’ll look at that next week.<\/p>\n
Bonus chatter<\/b>: If you wanted to express this as a pure revert rather than a merge, then omit the -p A<\/code> from the command lines. But using the merge has the nice side effect of assigning git blame<\/code> to the commits that led to A. The commits M1 and M2 will never be assigned blame, which makes sense, since all their changes were reverted.<\/p>\n
That nice side effect on git blame<\/code> means that this technique is useful if you are reverting the last change, since it takes the change and its revert out of the git blame<\/code>.<\/p>\n
\u00b9 Note that the topologically equivalent diagram does occur in nature:<\/p>\n\n\n\n\n\n
A<\/td>\n\u2190 \u2190 \u2190 \u2190 \u2190<\/td>\nM3<\/td>\n<\/tr>\n
 <\/td>\n\u2196\ufe0e<\/td>\n\u00a0<\/td>\n\u2199\ufe0e<\/td>\n<\/tr>\n
\u00a0<\/td>\nM1<\/td>\n\u2190<\/td>\nM2<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
This represents the situation where a no-fast-forward merge is taken from a topic branch.<\/p>\n
\n