list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: Git Mailing List <>
Subject: How to produce a loose ref+size explosion via pruning + git-gc
Date: Thu, 08 Feb 2018 16:37:32 +0100	[thread overview]
Message-ID: <> (raw)

I'll probably submit docs for this eventually, but the docs in my
--prune-tags series were already hard enough to review. Try running this

        rm -rf /tmp/git &&
        git clone /tmp/git &&
        cd /tmp/git >/dev/null &&
        du -sh .git &&
        git rev-list --all origin/master.. | wc -l &&
        for clone in gitster peff avar chriscool mhagger pclouds Microsoft
            git remote add $clone$clone/git &&
            git fetch -q $clone
        done &&
        git gc &&
        du -sh .git &&
        git rev-list --all origin/master.. | wc -l &&
        git fetch -q origin --prune 'refs/tags/*:refs/tags/*' &&
        for remote in $(git remote | grep -v origin)
            git remote rm $remote
        done &&
        git gc &&
        du -sh .git &&
        git rev-list --all origin/master.. | wc -l

The output is:

    108M    .git
    160M    .git
    1.9G    .git

I.e. a fresh clone of git.git is 108MB, add a few more repos that have
diverged quite a bit in its network ad it's 160MB repacked.

Now remove those remotes and "git gc" and it's 1.9GB, even though it's
divergent by the same 2222 commits from master as the 108MB, but after

    git prune --expire=now

It becomes ~108MB again.

Now this is all expected behavior, we've made a bunch of objects
unreferenced, so they all get exploded into loose objects, which takes a
lot of space.

It's an interesting caveat when setting fetch.prune=true on checkouts
that didn't previously have it and might have lots of brances to be

For reasons I won't go into I'd had that disabled for a while here at
work, and after re-enabling it we had some repos whose .git is usually
2.5G explode to 30G once git-gc ran.

The workaround is to set gc.pruneExpire low enough that when the gc hits
all those objects get deleted, I set it to 1 day (from the default of 2

But it doesn't help with repos that have already run git-gc and exploded
in size, much to the confusion of users on those systems, those need a
manual git-prune.

Potential solutions to this have been discussed ad-nauseam here on
list. Let's not go into that (unless someone feels like it).

I mainly wanted to send this for later reference, and have some
searchable record in case someone's confused when they turn on prune and
their repo increases to 10x the previous size.

                 reply	other threads:[~2018-02-08 15:37 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: How to produce a loose ref+size explosion via pruning + git-gc' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).