Git revert vs. git show -R & git apply -3

Question

Git revert vs. git show -R & git apply -3

Problem

My git repository has a huge number of objects (about 600 thousand, consisting of text and binary files, and the total amount of packages is 20 GB), and it git reverttakes a very long time (about 15 minutes) to finish. git gc, which itself takes longer (about 40 minutes), did not help.

Then I had the idea that I was doing the reverse patch of the command with interest git show --binary -R <sha1> > /tmp/x, merge-apply it to the index and working directory on git apply -3 /tmp/x, and then git commitright after that to create a "revert commit". He worked and completed his work in less than 30 seconds.

Question

What does git revertexactly that, and I can skip if I use git show --binary -R, git apply -3and then git commitinstead of the former?

I assumed that the two operations were the same, but from the observation that I explained above git revert, does something more than git show --binary -R, then git apply -3.

Note that merge conflicts are not a problem; they often happen, and I correct them every time without problems. It also git apply -3detects them correctly.

auto-gc is off.

Update

I discovered one problem; if the reverse patch contains the deletion of the file, and the contents of this file is different from the patch, git apply -3displays error: <filename>: patch does not applyand exits without touching the index. git revertsets such files in conflict with deleted by them(reported git status) in such cases.