我是否需要在裸回购版上运行git gc？ [英] Do I ever need to run git gc on a bare repo?

问题描述

man git-gc 在它里面没有明显的答案，我也没有对Google有任何好运（尽管我可能刚刚使用了错误的搜索条件）。

我知道你应该偶尔在本地存储库上运行 git gc 来修剪悬空对象并压缩历史记录等等 - 但是它是一个共享的裸存储库，容易受到这些相同的问题影响？

如果重要的话，我们的工作流程是多个开发人员从共享网络驱动器上抽取和推送到裸存储库。 中央存储库是使用 git init --bare --shared 创建的。

解决方案 div>

正如 Jefromi 对， git gc 应该在正常使用裸仓库期间自动调用。

我刚刚运行 git gc - 在两个裸露的，共享的存储库已被积极使用的情况下，其中约38人在过去的3-4周内提交，另外约388人在约3个月内提交。没有人在任一存储库上手动运行 git gc 。

更小的存储库

  $ git count-objects 
 333个对象，595千字节
 
 $ git count-objects -v 
 count：333 
 size：595 
 in-pack：0 
 packs：0 
 size-pack：0 
 prune-packable：0 
垃圾：0 
 
 $ git gc --aggressive 
计数对象：325，完成。 
使用多达4个线程的增量压缩。 
压缩对象：100％（323/323），完成。 
写作对象：100％（325/325），完成。 
总计325（增量209），重用0（增量0）
删除重复对象：完成100％（256/256）。 
 
 $ git count-objects -v 
 count：8 
 size：6 
 in-pack：325 
 packs：1 
 size -pack：324 
 prune-packable：0 
垃圾：0 
 
 $ git count-objects 
 8个对象，6千字节
  
 $ h $> code $ git count 
 
 $ h $> -objects 
 4315对象，11483千字节
 
 $ git count-objects -v 
 count：4315 
 size：11483 
 in-pack：9778 
包：20 
包装：15726 
修剪包装：1395 
垃圾：0 
 
 $ git gc --ggressive 
计数对象：8548，完成。 
使用多达4个线程的增量压缩。 
压缩对象：100％（8468/8468），完成。 
写作对象：100％（8548/8548），完成。 
共计8548（delta 7007），重用0（delta 0）
删除重复对象：100％（256/256），完成。 
 
 $ git count-objects -v 
 count：0 
 size：0 
 in-pack：8548 
 packs：1 
 size -pack：8937 
 prune-packable：0 
垃圾：0 
 
 $ git count-objects 
 0个对象，0千字节
  

我希望在我 gc 编辑这两个存储库之前想到它，但如果没有 - aggressive 选项，我应该运行 git gc 来查看差异。幸运的是，我还有一个中型活动存储库可供测试（164个提交将近2个月）。

-v
计数：1279
尺寸：1574
包装内容：2078
包装：6
尺寸包装：2080
修剪包装：607
垃圾：0

$ git gc
计数对象：1772，完成。
使用多达4个线程的增量压缩。
压缩对象：完成100％（1073/1073）。
写作对象：100％（1772/1772），完成。
合计1772（delta 1210），重用1050（delta 669）
删除重复对象：完成100％（256/256）。

$ git count-objects -v
count：0
size：0
in-pack：1772
packs：1
size -pack：1092
prune-packable：0
垃圾：0

$ git gc --ggressive
计数对象：1772，完成。
使用多达4个线程的增量压缩。
压缩对象：100％（1742/1742），完成。
写作对象：100％（1772/1772），完成。
总计1772（delta 1249），重用0（delta 0）

$ git count-objects -v
count：0
size：0
包装内容：1772
包装：1
尺寸包装：1058
修剪包装：0
垃圾：0

运行 git gc 清楚地在 count-objects ，即使我们经常从这个存储库中 push to和 fetch 。但是阅读 git config ，我注意到默认的松散对象限制是6700，我们显然尚未达到。

因此，看起来结论是 no ，您不需要 在裸回购库上手动运行 git gc ; 默认设置为 gc.auto ，这可能需要很长时间才会自动进行垃圾回收。

---

_{^* 通常，您不需要运行 git gc 。但有时你可能会被绑在空间，你应该运行 git gc 手动或将 gc.auto 设置为较低的值。虽然我的问题很简单，但好奇。}

man git-gc doesn't have an obvious answer in it, and I haven't had any luck with Google either (although I might have just been using the wrong search terms).

I understand that you should occasionally run git gc on a local repository to prune dangling objects and compress history, among other things -- but is a shared bare repository susceptible to these same issues?

If it matters, our workflow is multiple developers pulling from and pushing to a bare repository on a shared network drive. The "central" repository was created with git init --bare --shared.

解决方案

As Jefromi commented on Dan's answer, git gc should be called automatically called during "normal" use of a bare repository.

I just ran git gc --aggressive on two bare, shared repositories that have been actively used; one with about 38 commits the past 3-4 weeks, and the other with about 488 commits over roughly 3 months. Nobody has manually run git gc on either repository.

Smaller repository

$ git count-objects
333 objects, 595 kilobytes

$ git count-objects -v
count: 333
size: 595
in-pack: 0
packs: 0
size-pack: 0
prune-packable: 0
garbage: 0

$ git gc --aggressive
Counting objects: 325, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (323/323), done.
Writing objects: 100% (325/325), done.
Total 325 (delta 209), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.

$ git count-objects -v
count: 8
size: 6
in-pack: 325
packs: 1
size-pack: 324
prune-packable: 0
garbage: 0

$ git count-objects
8 objects, 6 kilobytes

Larger repository

$ git count-objects
4315 objects, 11483 kilobytes

$ git count-objects -v
count: 4315
size: 11483
in-pack: 9778
packs: 20
size-pack: 15726
prune-packable: 1395
garbage: 0

$ git gc --aggressive
Counting objects: 8548, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8468/8468), done.
Writing objects: 100% (8548/8548), done.
Total 8548 (delta 7007), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.

$ git count-objects -v
count: 0
size: 0
in-pack: 8548
packs: 1
size-pack: 8937
prune-packable: 0
garbage: 0

$ git count-objects
0 objects, 0 kilobytes

I wish I had thought of it before I gced these two repositories, but I should have run git gc without the --aggressive option to see the difference. Luckily I have a medium-sized active repository left to test (164 commits over nearly 2 months).

$ git count-objects -v
count: 1279
size: 1574
in-pack: 2078
packs: 6
size-pack: 2080
prune-packable: 607
garbage: 0

$ git gc
Counting objects: 1772, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1073/1073), done.
Writing objects: 100% (1772/1772), done.
Total 1772 (delta 1210), reused 1050 (delta 669)
Removing duplicate objects: 100% (256/256), done.

$ git count-objects -v
count: 0
size: 0
in-pack: 1772
packs: 1
size-pack: 1092
prune-packable: 0
garbage: 0

$ git gc --aggressive
Counting objects: 1772, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1742/1742), done.
Writing objects: 100% (1772/1772), done.
Total 1772 (delta 1249), reused 0 (delta 0)

$ git count-objects -v
count: 0
size: 0
in-pack: 1772
packs: 1
size-pack: 1058
prune-packable: 0
garbage: 0

Running git gc clearly made a large dent in count-objects, even though we regularly push to and fetch from this repository. But upon reading the manpage for git config, I noticed that the default loose object limit is 6700, which we apparently had not yet reached.

So it appears that the conclusion is no, you don't need to run git gc manually on a bare repo;^* but with the default setting for gc.auto, it might be a long time before garbage collection occurs automatically.

---

_{^* Generally, you shouldn't need to run git gc. But sometimes you might be strapped for space and you should run git gc manually or set gc.auto to a lower value. My case for the question was simple curiosity, though.}

这篇关于我是否需要在裸回购版上运行git gc？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！