我的git存储库有大量的对象（近600k，包括文本和二进制文件，包文件的总和是20GiB），git revert需要很长时间（大约15分钟）到完。 git gc，它本身需要更长的时间（大约40分钟），没有帮助。
然后我提出了一个想法，即我通过git show --binary -R <sha1> > /tmp/x对感兴趣的提交进行反向修补，然后通过git apply -3 /tmp/x将其合并到索引和工作目录，然后{{在那之后产生“恢复提交”。它起作用，并在不到30秒的时间内完成了它的工作。
git commit完全做了什么，如果我使用git revert，git show --binary -R然后git apply -3而不是前者，我可能会错过什么？
我认为这两项操作是相同的，但从我上面解释的观察git commit做的事情远远超过git revert然后git show --binary -R。
请注意，合并冲突不是问题;它们经常发生，我每次都会毫无问题地修复它们。此外，git apply -3似乎正确检测到它们。
auto-gc已关闭。
更新
我发现了一个问题;如果反向修补程序包含文件删除且该文件的内容与修补程序不同，则git apply -3会打印git apply -3并退出而不会触及索引。在这种情况下，error: <filename>: patch does not apply会将此类文件设置为包含git revert的冲突状态（由deleted by them报告）。
我使用git作为整个Linux系统的备份系统，其发行版是Linux From Scratch。由于对包管理系统持怀疑态度，我正在通过使用git手动管理包来玩我的操作系统。我为我安装的每个软件包进行了一对提交，以便在安装之前/之后拍摄快照。这些对使我能够通过git status卸载所需的包。
我知道git不应该用作备份系统。我使用git revert <the-commit-after-install>将元数据（所有者/权限等）存储在二进制文件中（这会在恢复时经常导致冲突）。我选择git是因为它被广泛使用并且看起来很稳定。此外，“持怀疑态度”也是选择非备份软件以备份的一部分。
我听说git不擅长处理二进制文件，特别是大文件。事实上，它对二进制文件做得不错，直到我安装了TeXLive 2016，这是我操作系统上TeXLive的第二个版本。
在大多数情况下，我在升级包时使用metastore。首先，我git revert一个旧包来卸载它。然后我“全新安装”一个新软件包，这样每个文件的历史记录都不会错综复杂（当我真的想要卸载它时，一系列修改就会变得更难）。在git revert完成之前我不能离开shell，因为我必须在此之后快速安装现在缺少的新软件包，否则会冒我的操作系统的稳定性。