在git rebase -i中放弃提交不会减小.git文件夹的大小 [英] Dropping a commit in git rebase -i does not reduce the size of .git folder

问题描述

我有一个git仓库，其中 .git 文件夹是 7MB 。然后我添加并提交了一个 16MB 的.exe文件，后面跟着：

  git gc  -  - 扩大&& git prune 
  

在上面的 .git 文件夹现在是 23MB 。

接下来我做了一个 git rebase -i 和选择 drop ：

<对于引入16MB文件的提交（ c8185ff ），我完成了rebase并再次运行：

  git gc --aggressive&& git prune 
  

现在当我测量 .git 文件夹仍然是 23MB

。

上面执行的 git rebase 不会删除提交完全来自历史记录 - 好像文件从未被引入 - 并因此将 .git 文件夹带回 7MB 大小？

我也尝试过对存储库进行全新的克隆，并且大小仍然<23MB - 我假设在进行全新克隆时，reflog将被清除。

解决方案

默认情况下， git gc 只修剪宽松超过2周的对象。

要强制修剪所有对象，请使用 - prune = all ：

  git -c gc.reflogExpire = now gc --prune = all 
  

但是，如果对象仍然可以访问通过任何引用（例如 origin / master 或远程引用），它都不会被修剪。

这就是为什么我们还必须设置 。





（For git prune [gc后不需要]，它是 - expire ）

I have a git repository where the .git folder is 7MB. I have then added and committed an .exe file that is 16MB followed by:

git gc --aggressive && git prune

After the above my .git folder is now 23MB.

Next I have done a git rebase -i and selected drop:

on the commit (c8185ff) that introduced the 16MB file, I completed the rebase and again ran:

git gc --aggressive && git prune

Now when I measure the .git folder its still 23MB.

Should git rebase performed above not remove the commit completely from history - as if the file was never introduced - and hence bring the .git folder back to the 7MB size?

I also tried to do a fresh clone of the repository and the size is still 23MB - I assume the reflog will be cleared when doing a fresh clone.

解决方案

By default, git gc only prune loose objects older than 2 weeks.

To force a prune on all objects, use --prune=all:

git -c gc.reflogExpire=now gc --prune=all

But, if the object is still reachable through any reference (remote one like origin/master for example, or the reflog), it won't be pruned.

That's why we have to also set the gc.reflogExpire configuration to now.

(For git prune [not necessary after a gc], it's --expire)

这篇关于在git rebase -i中放弃提交不会减小.git文件夹的大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！