blocks|key|1308273|text|您是否尝试过使用git+repack|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1308274|entityMap|0|LINK|mutability|MUTABLE|url|http://www.kernel.org/pub/software/scm/git/docs/git-repack.html^0|8|A|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Did you try using <a href="http://www.kernel.org/pub/software/scm/git/docs/git-repack.html" rel="nofollow noreferrer">git repack</a>?

blocks|key|1308337|text|存储在.git中的其他git对象包括树、提交和标记。提交和标记很小，但是树可以变得很大，特别是当您的存储库中有非常多的小文件时。你有多少个文件和多少个提交？|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1308338|entityMap^0|3|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Other git objects stored in <code>.git</code> include trees, commits, and tags. Commits and tags are small, but trees can get big particularly if you have a very large number of small files in your repository. How many files and how many commits do you have?

blocks|key|1523500|text|您确定只计算.pack文件而不计算.idx文件吗？它们与.pack文件在同一目录中，但没有任何存储库数据(正如扩展名所示，它们只不过是相应包的索引-事实上，如果您知道正确的命令，就可以很容易地从包文件重新创建它们，并且git本身在克隆时会这样做，因为只有包文件是使用原生git协议传输的)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523501|作为一个有代表性的示例，我查看了linux-2.6存储库的本地克隆：|1523502|$+du+-c+*.pack
505888++total

$+du+-c+*.idx
34300+++total|code-block|syntax|javascript|1523503|这表明7%25左右的扩张应该是常见的。|1523504|也有objects/之外的文件；根据我的个人经验，其中index和gitk.cache往往是最大的(在我克隆的Linux2.6存储库中总共有1100万个文件)。|offset|length|style|CODE|1523505|entityMap^0|0|0|0|0|2|8|R|5|X|A|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]|$M|Z|N|10|O|P]|$M|11|N|12|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|R|$]]

Are you sure you are counting just the .pack files and not the .idx files? They are in the same directory as the .pack files, but do not have any of the repository data (as the extension indicates, they are nothing more than indexes for the corresponding pack &mdash; in fact, if you know the correct command, you can easily recreate them from the pack file, and git itself does it when cloning, as only a pack file is transferred using the native git protocol).

As a representative sample, I took a look at my local clone of the linux-2.6 repository:

<pre><code>$ du -c *.pack
505888 total

$ du -c *.idx
34300 total
</code></pre>

Which indicates an expansion of around 7% should be common.

There are also the files outside <code>objects/</code>; in my personal experience, of them <code>index</code> and <code>gitk.cache</code> tend to be the biggest ones (totaling 11M in my clone of the linux-2.6 repository).

blocks|key|1308472|text|我最近把错误的远程存储库放入了本地存储库(git+remote+add+...和git+remote+update)。删除不需要的远程引用、分支和标记后，我仍然有1.4+had+(!)我的存储库中浪费的空间。我只能通过用git+clone+file:///path/to/repository克隆它来摆脱它。请注意，在克隆本地存储库时，file://会带来很大的不同--只复制被引用的对象，而不是整个目录结构。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1308473|编辑:这是Ian在新的存储库中重新创建所有分支的一个代码行：|1308474|d1=#original+repo
d2=#new+repo+(must+already+exist)
cd+$d1
for+b+in+$(git+branch+%7C+cut+-c+3-)
do
++++git+checkout+$b
++++x=$(git+rev-parse+HEAD)
++++cd+$d2
++++git+checkout+-b+$b+$x
++++cd+$d1
done|code-block|syntax|javascript|1308475|entityMap^0|L|I|14|H|32|10|4O|7|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|Y|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|N|$]]

I recently pulled the wrong remote repository into the local one (<code>git remote add ...</code> and <code>git remote update</code>). After deleting the unwanted remote ref, branches and tags I still had 1.4GB (!) of wasted space in my repository. I was only able to get rid of this by cloning it with <code>git clone file:///path/to/repository</code>. Note that the <code>file://</code> makes a world of difference when cloning a local repository - only the referenced objects are copied across, not the whole directory structure.

Edit: Here's Ian's one liner for recreating all branches in the new repo:

<pre><code>d1=#original repo
d2=#new repo (must already exist)
cd $d1
for b in $(git branch | cut -c 3-)
do
 git checkout $b
 x=$(git rev-parse HEAD)
 cd $d2
 git checkout -b $b $x
 cd $d1
done
</code></pre>

blocks|key|1523600|text|git+gc已经做了一个git+repack，所以除非你要向它传递一些特殊的选项，否则手动重新打包是没有意义的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1523601|第一步是查看大部分空间是否(通常情况下是这样)是您的对象数据库。|1523602|git+count-objects+-v|code-block|syntax|javascript|1523603|这应该会给出一个报告，说明您的存储库中有多少未打包的对象，它们占用了多少空间，您有多少打包文件，以及它们占用了多少空间。|1523604|理想情况下，在重新打包之后，您将没有解包的对象和一个压缩文件，但一些未被当前分支直接引用的对象仍然存在并解包，这是非常正常的。|1523605|如果你有一个很大的包，你想知道是什么占用了空间，那么你可以列出组成包的对象以及它们是如何存储的。|1523606|git+verify-pack+-v+.git/objects/pack/pack-*.idx|1523607|请注意，verify-pack接受一个索引文件，而不是包文件本身。这给出了包中每个物体的报告，它的真实大小和包的大小，以及关于它是否被‘剥离’的信息，如果是的话，增量链的起源。|1523608|要查看您的存储库中是否有非常大的对象，您可以在第四列的第三列(例如%7C+sort+-k3n)上对输出进行数字排序。|1523609|从这个输出中，您将能够使用git+show命令查看任何对象的内容，尽管不可能确切地看到该对象在存储库的提交历史记录中被引用的位置。如果您需要这样做，请尝试this+question中的内容。|1523610|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/460331/^0|0|6|C|A|0|0|0|0|0|0|0|4|B|0|X|B|0|D|8|25|D|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1D|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|1E|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|1F|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|1G|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1H|8|@]|D|@]|E|$]]|$1|S|3|T|5|J|7|1I|8|@]|D|@]|E|$K|L]]|$1|U|3|V|5|6|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1P|8|@$9|1Q|A|1R|B|C]]|D|@$9|1S|A|1T|1|1U]]|E|$]]|$1|10|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]]|11|$12|$5|13|14|15|E|$16|17]]]]

<code>git gc</code> already does a <code>git repack</code> so there is no sense in manually repacking unless you are going to be passing some special options to it.

The first step is to see whether the majority of space is (as would normally be the case) your object database.

<pre><code>git count-objects -v
</code></pre>

This should give a report of how many unpacked objects there are in your repository, how much space they take up, how many pack files you have and how much space they take up.

Ideally, after a repack, you would have no unpacked objects and one pack file but it's perfectly normal to have some objects which aren't directly reference by current branches still present and unpacked.

If you have a single large pack and you want to know what is taking up the space then you can list the objects which make up the pack along with how they are stored.

<pre><code>git verify-pack -v .git/objects/pack/pack-*.idx
</code></pre>

Note that <code>verify-pack</code> takes an index file and not the pack file itself. This give a report of every object in the pack, its true size and its packed size as well as information about whether it's been 'deltified' and if so the origin of delta chain.

To see if there are any unusally large objects in your repository you can sort the output numerically on the third of fourth columns (e.g. <code>| sort -k3n</code>).

From this output you will be able to see the contents of any object using the <code>git show</code> command, although it is not possible to see exactly where in the commit history of the repository the object is referenced. If you need to do this, try something from <a href="https://stackoverflow.com/questions/460331/">this question</a>.

blocks|key|1523632|text|在做git+filter-branch+&+git之前，你应该检查一下你的资源库中存在的标签。任何具有持续集成和部署等内容的自动标记的实际系统都会使未绑定的对象仍然被这些标记引用，因此gc无法删除它们，而你仍然会想为什么repo的大小仍然如此之大。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523633|清除所有不需要的东西的最好方法是运行git-filter+&+git+gc，然后将master推送到一个新的空代码库。新的裸存储存库将有清理过的树。|1523634|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

before doing git filter-branch &amp; git gc you should review tags that are present in your repo. Any real system which has automatic tagging for things like continuous integration and deployments will make unwated objects still refrenced by these tags , hence gc cant remove them and you will still keep wondering why the size of repo is still so big.

The best way to get rid of all un-wanted stuff is to run git-filter &amp; git gc and then push master to a new bare repo. The new bare repo will have the cleaned up tree.

blocks|key|1523663|text|仅供参考，您最终可能会保留不需要的对象的最大原因是git维护了reflog。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523664|当你不小心删除了你的主分支或者以某种方式灾难性地损坏了你的存储库时，reflog是为了挽救你的麻烦。|1523665|解决这个问题的最简单的方法是在压缩之前截断reflog(只需确保您永远不想回到reflog中的任何提交)。|1523666|git+gc+--prune=now+--aggressive
git+repack|code-block|syntax|javascript|1523667|这与git+gc+--prune=today的不同之处在于它会立即使整个reflog过期。|offset|length|style|CODE|1523668|entityMap^0|0|0|0|0|2|K|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|V|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Just FYI, the biggest reason why you may end up with unwanted objects being kept around is that git maintains a reflog.

The reflog is there to save your butt when you accidentally delete your master branch or somehow otherwise catastrophically damage your repository.

The easiest way to fix this is to truncate your reflogs before compressing (just make sure that you never want to go back to any of the commits in the reflog).

<pre><code>git gc --prune=now --aggressive
git repack
</code></pre>

This is different from <code>git gc --prune=today</code> in that it expires the entire reflog immediately.

blocks|key|1308656|text|我使用的一些脚本：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1308657|git-fatfiles文件|1308658|git+rev-list+--all+--objects+%7C+\
++++sed+-n+$(git+rev-list+--objects+--all+%7C+\
++++cut+-f1+-d'+'+%7C+\
++++git+cat-file+--batch-check+%7C+\
++++grep+blob+%7C+\
++++sort+-n+-k+3+%7C+\
++++tail+-n40+%7C+\
++++while+read+hash+type+size;+do+
+++++++++echo+-n+"-e+s/$hash/$size/p+";
++++done)+%7C+\
++++sort+-n+-k1|code-block|syntax|javascript|1308659|...
89076+images/screenshots/properties.png
103472+images/screenshots/signals.png
9434202+video/parasite-intro.avi|1308660|如果需要更多行，请参阅相邻答案中的Perl版本：https://stackoverflow.com/a/45366030/266720|offset|length|1308661|video/parasite.avi-消除(适用于git)：|style|CODE|1308662|git+filter-branch+-f++--index-filter+\
++++'git+rm+--force+--cached+--ignore-unmatch+video/parasite-intro.avi'+\
+++++--+--all
rm+-Rf+.git/refs/original+&&+\
++++git+reflog+expire+--expire=now+--all+&&+\
++++git+gc+--aggressive+&&+\
++++git+prune|1308663|注意:第二个脚本旨在从Git中完全删除信息(包括来自reflogs的所有信息)。请谨慎使用。|1308664|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/45366030/266720^0|0|0|0|0|O|17|0|0|0|I|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|F|7|17|8|@]|9|@]|A|$G|H]]|$1|K|3|L|5|6|7|18|8|@]|9|@$M|19|N|1A|1|1B]]|A|$]]|$1|O|3|P|5|6|7|1C|8|@$M|1D|N|1E|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|F|7|1F|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|1G|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

Some scripts I use:

<h1>git-fatfiles</h1>

<pre><code>git rev-list --all --objects | \
 sed -n $(git rev-list --objects --all | \
 cut -f1 -d' ' | \
 git cat-file --batch-check | \
 grep blob | \
 sort -n -k 3 | \
 tail -n40 | \
 while read hash type size; do 
 echo -n "-e s/$hash/$size/p ";
 done) | \
 sort -n -k1
</code></pre>



<pre><code>...
89076 images/screenshots/properties.png
103472 images/screenshots/signals.png
9434202 video/parasite-intro.avi
</code></pre>

If you want more lines, see also Perl version in a neighbouring answer: <a href="https://stackoverflow.com/a/45366030/266720">https://stackoverflow.com/a/45366030/266720</a>

<h1>git-eradicate (for <code>video/parasite.avi</code>):</h1>

<pre><code>git filter-branch -f --index-filter \
 'git rm --force --cached --ignore-unmatch video/parasite-intro.avi' \
 -- --all
rm -Rf .git/refs/original &amp;&amp; \
 git reflog expire --expire=now --all &amp;&amp; \
 git gc --aggressive &amp;&amp; \
 git prune
</code></pre>

Note: the second script is designed to remove info from Git completely (including all info from reflogs). Use with caution.

blocks|key|1308746|text|如果您意外地添加了大量文件并暂存了它们，而不一定提交它们，就会发生这种情况。这可能会发生在rails应用程序中，当你运行bundle+install+--deployment，然后意外地git+add+.，然后你会看到所有的文件添加在vendor/bundle下，你取消了它们，但它们已经进入git历史记录，所以你必须应用Vi's+answer并通过vendor/bundle更改video/parasite-intro.avi，然后运行他提供的第二个命令。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1308747|您可以看到git+count-objects+-v的不同之处，在我的例子中，应用脚本之前的大小为52K，应用后的大小为3.8K。|1308748|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/14329983/1248725^0|19|5|1O|R|2L|9|39|D|4V|D|5A|O|4H|B|0|0|5|K|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@$9|12|A|13|1|14]]|E|$]]|$1|F|3|G|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

This can happen if you added a big chunk of files accidentally and staged them, not necessarily commit them. This can happen in a <code>rails</code> app when you run <code>bundle install --deployment</code> and then accidentally <code>git add .</code> then you see all the files added under <code>vendor/bundle</code> you unstage them but they already got into git history, so you have to apply <a href="https://stackoverflow.com/a/14329983/1248725">Vi's answer</a> and change <code>
video/parasite-intro.avi</code> by <code>vendor/bundle</code> then run the second command he provides.

You can see the difference with <code>git count-objects -v</code> which in my case before applying the script had a size-pack: of 52K and after applying it was 3.8K.

blocks|key|1308818|text|如果想要找出哪些文件占用了git存储库中的空间，请运行|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1308819|git+verify-pack+-v+.git/objects/pack/*.idx+%7C+sort+-k+3+-n+%7C+tail+-5|offset|length|style|CODE|1308820|然后，提取占用最多空间的blob引用(最后一行)，并检查占用这么多空间的文件名|1308821|git+rev-list+--objects+--all+%7C+grep+<reference>|1308822|这甚至可能是你用git+rm删除的一个文件，但git会记住它，因为仍然有对它的引用，比如标签、远程和引用日志。|1308823|一旦知道了要删除的文件，我建议您使用git+forget-blob|1308824|https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/|1308825|它很容易使用，只需这样做|1308826|git+forget-blob+file-to-forget|1308827|这将从git中删除每个引用，从历史记录中的每个提交中删除blob，并运行垃圾收集来释放空间。|1308828|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1V|0|0|0|1B|0|8|6|0|I|F|0|0|2V|0|0|0|0|U|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@$D|16|E|17|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|18|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|19|8|@$D|1A|E|1B|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1C|8|@$D|1D|E|1E|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1F|8|@$D|1G|E|1H|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1I|8|@]|9|@$D|1J|E|1K|1|1L]]|A|$]]|$1|R|3|S|5|6|7|1M|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1N|8|@$D|1O|E|1P|F|G]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|Y|$Z|$5|10|11|12|A|$13|Q]]]]

If you want to find what files are taking up space in your git repository, run

<code>git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5</code>

Then, extract the blob reference that takes up the most space (the last line), and check the filename that is taking so much space

<code>git rev-list --objects --all | grep &lt;reference&gt;</code>

This might even be a file that you removed with <code>git rm</code>, but git remembers it because there are still references to it, such as tags, remotes and reflog.

Once you know what file you want to get rid of, I recommend using <code>git forget-blob</code>

<a href="https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/" rel="noreferrer">https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/</a>

It is easy to use, just do

<code>git forget-blob file-to-forget</code>

This will remove every reference from git, remove the blob from every commit in history, and run garbage collection to free up the space.

blocks|key|1523973|text|如果你想查看所有斑点的大小，Vi答案中的git-fatfiles脚本很不错，但它太慢了，以至于无法使用。我取消了40行输出的限制，它试图使用我计算机的所有RAM，而不是完成。此外，在对输出进行求和以查看文件使用的所有空间时，它会给出不准确的结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1523974|我用rust重写了它，我发现它比其他语言更不容易出错。如果传递了--directories标志，我还添加了汇总各个目录中所有提交所使用的空间的功能。可以指定路径以将搜索限制在特定的文件或目录。|offset|length|style|CODE|1523975|src/main.rs：|1523976|use+std::{
++++collections::HashMap,
++++io::{self,+BufRead,+BufReader,+Write},
++++path::{Path,+PathBuf},
++++process::{Command,+Stdio},
++++thread,
};

use+bytesize::ByteSize;
use+structopt::StructOpt;

#[derive(Debug,+StructOpt)]
#[structopt()]
pub+struct+Opt+{
++++#[structopt(
++++++++short,
++++++++long,
++++++++help("Show+the+size+of+directories+based+on+files+committed+in+them.")
++++)]
++++pub+directories:+bool,

++++#[structopt(help("Optional:+only+show+the+size+info+about+certain+paths."))]
++++pub+paths:+Vec<String>,
}

///+The+paths+list+is+a+filter.+If+empty,+there+is+no+filtering.
///+Returns+a+map+of+object+ID+->+filename.
fn+get_revs_for_paths(paths:+Vec<String>)+->+HashMap<String,+PathBuf>+{
++++let+mut+process+=+Command::new("git");
++++let+mut+process+=+process.arg("rev-list").arg("--all").arg("--objects");

++++if+!paths.is_empty()+{
++++++++process+=+process.arg("--").args(paths);
++++};

++++let+output+=+process
++++++++.output()
++++++++.expect("Failed+to+execute+command+git+rev-list.");

++++let+mut+id_map+=+HashMap::new();
++++for+line+in+io::Cursor::new(output.stdout).lines()+{
++++++++if+let+Some((k,+v))+=+line
++++++++++++.expect("Failed+to+get+line+from+git+command+output.")
++++++++++++.split_once('+')
++++++++{
++++++++++++id_map.insert(k.to_owned(),+PathBuf::from(v));
++++++++}
++++}
++++id_map
}

///+Returns+a+map+of+object+ID+to+size.
fn+get_sizes_of_objects(ids:+Vec<&String>)+->+HashMap<String,+u64>+{
++++let+mut+process+=+Command::new("git")
++++++++.arg("cat-file")
++++++++.arg("--batch-check=%25(objectname)+%25(objecttype)+%25(objectsize:disk)")
++++++++.stdin(Stdio::piped())
++++++++.stdout(Stdio::piped())
++++++++.spawn()
++++++++.expect("Failed+to+execute+command+git+cat-file.");
++++let+mut+stdin+=+process.stdin.expect("Could+not+open+child+stdin.");

++++let+ids:+Vec<String>+=+ids.into_iter().cloned().collect();+//+copy+data+for+thread

++++//+Stdin+will+block+when+the+output+buffer+gets+full,+so+it+needs+to+be+written
++++//+in+a+thread:
++++let+write_thread+=+thread::spawn(%7C%7C+{
++++++++for+obj_id+in+ids+{
++++++++++++writeln!(stdin,+"{}",+obj_id).expect("Could+not+write+to+child+stdin");
++++++++}
++++++++drop(stdin);
++++});

++++let+output+=+process
++++++++.stdout
++++++++.take()
++++++++.expect("Could+not+get+output+of+command+git+cat-file.");

++++let+mut+id_map+=+HashMap::new();
++++for+line+in+BufReader::new(output).lines()+{
++++++++let+line+=+line.expect("Failed+to+get+line+from+git+command+output.");

++++++++let+line_split:+Vec<&str>+=+line.split('+').collect();

++++++++//+skip+non-blob+objects
++++++++if+let+[id,+"blob",+size]+=+&line_split[..]+{
++++++++++++id_map.insert(
++++++++++++++++id.to_string(),
++++++++++++++++size.parse::<u64>().expect("Could+not+convert+size+to+int."),
++++++++++++);
++++++++};
++++}
++++write_thread.join().unwrap();
++++id_map
}

fn+main()+{
++++let+opt+=+Opt::from_args();

++++let+revs+=+get_revs_for_paths(opt.paths);
++++let+sizes+=+get_sizes_of_objects(revs.keys().collect());

++++//+This+skips+directories+(they+have+no+size+mapping).
++++//+Filename+->+size+mapping+tuples.+Files+are+present+in+the+list+more+than+once.
++++let+file_sizes:+Vec<(&Path,+u64)>+=+sizes
++++++++.iter()
++++++++.map(%7C(id,+size)%7C+(revs[id].as_path(),+*size))
++++++++.collect();

++++//+(Filename,+size)+tuples.
++++let+mut+file_size_sums:+HashMap<&Path,+u64>+=+HashMap::new();
++++for+(mut+path,+size)+in+file_sizes.into_iter()+{
++++++++if+opt.directories+{
++++++++++++//+For+file+path+"foo/bar",+add+these+bytes+to+path+"foo/"
++++++++++++let+parent+=+path.parent();
++++++++++++path+=+match+parent+{
++++++++++++++++Some(parent)+=>+parent,
++++++++++++++++_+=>+{
++++++++++++++++++++eprint!("File+has+no+parent+directory:+{}",+path.display());
++++++++++++++++++++continue;
++++++++++++++++}
++++++++++++};
++++++++}

++++++++*(file_size_sums.entry(path).or_default())+%2B=+size;
++++}
++++let+sizes:+Vec<(&Path,+u64)>+=+file_size_sums.into_iter().collect();

++++print_sizes(sizes);
}

fn+print_sizes(mut+sizes:+Vec<(&Path,+u64)>)+{
++++sizes.sort_by_key(%7C(_path,+size)%7C+*size);
++++for+file_size+in+sizes.iter()+{
++++++++//+The+size+needs+some+padding--a+long+size+is+as+long+as+a+tabstop
++++++++println!("{:10}{}",+ByteSize(file_size.1),+file_size.0.display())
++++}
}|code-block|syntax|javascript|1523977|Cargo.toml：|1523978|[package]
name+=+"git-fatfiles"
version+=+"0.1.0"
edition+=+"2018"
[dependencies]
structopt+=+{+version+=+"0.3"}
bytesize+=+{version+=+"1"}|1523979|选项：|1523980|USAGE:
++++git-fatfiles+[FLAGS]+[paths]...

FLAGS:
++++-d,+--directories++++Show+the+size+of+directories+based+on+files+committed+in+them.
++++-h,+--help+++++++++++Prints+help+information

ARGS:
++++<paths>...++++Optional:+only+show+the+size+info+about+certain+paths.|1523981|entityMap^0|0|W|D|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@$D|10|E|11|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|13|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|15|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|V|5|L|7|17|8|@]|9|@]|A|$M|N]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

The git-fatfiles script from Vi's answer is lovely if you want to see the size of all your blobs, but it's so slow as to be unusable. I removed the 40-line output limit, and it tried to use all my computer's RAM instead of finishing. Plus it would give inaccurate results when summing the output to see all space used by a file.
I rewrote it in rust, which I find to be less error-prone than other languages. I also added the feature of summing up the space used by all commits in various directories if the <code>--directories</code> flag is passed. Paths can be given to limit the search to certain files or directories.
src/main.rs:
<pre><code>use std::{
 collections::HashMap,
 io::{self, BufRead, BufReader, Write},
 path::{Path, PathBuf},
 process::{Command, Stdio},
 thread,
};

use bytesize::ByteSize;
use structopt::StructOpt;

#[derive(Debug, StructOpt)]
#[structopt()]
pub struct Opt {
 #[structopt(
 short,
 long,
 help(&quot;Show the size of directories based on files committed in them.&quot;)
 )]
 pub directories: bool,

 #[structopt(help(&quot;Optional: only show the size info about certain paths.&quot;))]
 pub paths: Vec&lt;String&gt;,
}

/// The paths list is a filter. If empty, there is no filtering.
/// Returns a map of object ID -&gt; filename.
fn get_revs_for_paths(paths: Vec&lt;String&gt;) -&gt; HashMap&lt;String, PathBuf&gt; {
 let mut process = Command::new(&quot;git&quot;);
 let mut process = process.arg(&quot;rev-list&quot;).arg(&quot;--all&quot;).arg(&quot;--objects&quot;);

 if !paths.is_empty() {
 process = process.arg(&quot;--&quot;).args(paths);
 };

 let output = process
 .output()
 .expect(&quot;Failed to execute command git rev-list.&quot;);

 let mut id_map = HashMap::new();
 for line in io::Cursor::new(output.stdout).lines() {
 if let Some((k, v)) = line
 .expect(&quot;Failed to get line from git command output.&quot;)
 .split_once(' ')
 {
 id_map.insert(k.to_owned(), PathBuf::from(v));
 }
 }
 id_map
}

/// Returns a map of object ID to size.
fn get_sizes_of_objects(ids: Vec&lt;&amp;String&gt;) -&gt; HashMap&lt;String, u64&gt; {
 let mut process = Command::new(&quot;git&quot;)
 .arg(&quot;cat-file&quot;)
 .arg(&quot;--batch-check=%(objectname) %(objecttype) %(objectsize:disk)&quot;)
 .stdin(Stdio::piped())
 .stdout(Stdio::piped())
 .spawn()
 .expect(&quot;Failed to execute command git cat-file.&quot;);
 let mut stdin = process.stdin.expect(&quot;Could not open child stdin.&quot;);

 let ids: Vec&lt;String&gt; = ids.into_iter().cloned().collect(); // copy data for thread

 // Stdin will block when the output buffer gets full, so it needs to be written
 // in a thread:
 let write_thread = thread::spawn(|| {
 for obj_id in ids {
 writeln!(stdin, &quot;{}&quot;, obj_id).expect(&quot;Could not write to child stdin&quot;);
 }
 drop(stdin);
 });

 let output = process
 .stdout
 .take()
 .expect(&quot;Could not get output of command git cat-file.&quot;);

 let mut id_map = HashMap::new();
 for line in BufReader::new(output).lines() {
 let line = line.expect(&quot;Failed to get line from git command output.&quot;);

 let line_split: Vec&lt;&amp;str&gt; = line.split(' ').collect();

 // skip non-blob objects
 if let [id, &quot;blob&quot;, size] = &amp;line_split[..] {
 id_map.insert(
 id.to_string(),
 size.parse::&lt;u64&gt;().expect(&quot;Could not convert size to int.&quot;),
 );
 };
 }
 write_thread.join().unwrap();
 id_map
}

fn main() {
 let opt = Opt::from_args();

 let revs = get_revs_for_paths(opt.paths);
 let sizes = get_sizes_of_objects(revs.keys().collect());

 // This skips directories (they have no size mapping).
 // Filename -&gt; size mapping tuples. Files are present in the list more than once.
 let file_sizes: Vec&lt;(&amp;Path, u64)&gt; = sizes
 .iter()
 .map(|(id, size)| (revs[id].as_path(), *size))
 .collect();

 // (Filename, size) tuples.
 let mut file_size_sums: HashMap&lt;&amp;Path, u64&gt; = HashMap::new();
 for (mut path, size) in file_sizes.into_iter() {
 if opt.directories {
 // For file path &quot;foo/bar&quot;, add these bytes to path &quot;foo/&quot;
 let parent = path.parent();
 path = match parent {
 Some(parent) =&gt; parent,
 _ =&gt; {
 eprint!(&quot;File has no parent directory: {}&quot;, path.display());
 continue;
 }
 };
 }

 *(file_size_sums.entry(path).or_default()) += size;
 }
 let sizes: Vec&lt;(&amp;Path, u64)&gt; = file_size_sums.into_iter().collect();

 print_sizes(sizes);
}

fn print_sizes(mut sizes: Vec&lt;(&amp;Path, u64)&gt;) {
 sizes.sort_by_key(|(_path, size)| *size);
 for file_size in sizes.iter() {
 // The size needs some padding--a long size is as long as a tabstop
 println!(&quot;{:10}{}&quot;, ByteSize(file_size.1), file_size.0.display())
 }
}
</code></pre>
Cargo.toml:
<pre><code>[package]
name = &quot;git-fatfiles&quot;
version = &quot;0.1.0&quot;
edition = &quot;2018&quot;
[dependencies]
structopt = { version = &quot;0.3&quot;}
bytesize = {version = &quot;1&quot;}
</code></pre>
Options:
<pre><code>USAGE:
 git-fatfiles [FLAGS] [paths]...

FLAGS:
 -d, --directories Show the size of directories based on files committed in them.
 -h, --help Prints help information

ARGS:
 &lt;paths&gt;... Optional: only show the size info about certain paths.
</code></pre>

blocks|key|1308979|text|检查stacktrace.log是值得的。它基本上是失败的跟踪提交的错误日志。我最近发现我的stacktrace.log是65.5+my，我的应用程序是66.7+my。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1308980|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It is worth checking the stacktrace.log. It is basically an error log for tracing commits that failed. I've recently found out that my stacktrace.log is 65.5GB and my app is 66.7GB.

145M = .git/objects/pack/

I wrote a script to add up the sizes of differences of each commit and the commit before it going backwards from the tip of each branch. I get 129MB, which is without compression and without accounting for same files across branches and common history among branches.

Git takes all those things into account so I would expect much much smaller repository. So why is .git so big?

I've done:

<pre><code>git fsck --full
git gc --prune=today --aggressive
git repack
</code></pre>

To answer about how many files/commits, I have 19 branches about 40 files in each. 
287 commits, found using:

<pre><code>git log --oneline --all|wc -l
</code></pre>

It should not be taking 10's of megabytes to store information about this.

Why is my git repository so big?

数据库

Perl

145M =.git/对象/包/我编写了一个脚本，在从每个分支的尖端向后返回之前，将每个提交和提交的差异大小相加。我得到了129MB，这是没有压缩的，也没有考虑分支之间相同的文件和分支之间的共同历史记录。Git将所有这些都考虑在内，所以我认为存储库要小得多。那么为什么.git会这么大呢？我已经做到了：git fsck ...

问为什么我的git库这么大？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么我的git库这么大？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么我的git库这么大？
EN