Re: Big repo not shrinking on repack or gc?

[Andreas Krey <a.krey@gmx.de>]

On Thu, 15 Jan 2015 12:23:00 +0000, Bryan Turner wrote:
...
> > Guess in the dark: "ls -l .git/objects/pack"
> > Do you see any .keep files?

Lots of. :-(

> I'm one of the Stash developers and just noticed this thread. If the
> repository in question has been forked via Stash there likely _will_
> be .keep files. Stash uses alternates for forks, so it's possible, by
> deleting those kept packs and pruning objects (which you've already
> done I see) that you will corrupt, or have already corrupted, some
> number of the forks.

There are a few forks in this stash instance, but the repository in
question is neither the source nor the destination of any.

So, git seems to be mostly out of the equation now (gc and repack
apparently doing what they are supposed to do), and the question
moves to 'how can stash let such a repo grow to that size'.


> (At the moment Stash packs "garbage" into a "dead
> pack" which it flags with a .keep, to ensure forks don't lose access
> to objects that once existed upstream that they still reference.)

Does it do so in any case even if there is no actual fork? That would
explain a lot - we are daily (force-)pushing new commit in there (and
potentially big ones) that become garbage the next day, and should
be cleaned up rather fast.

(We're pulling them into another non-stash repo for longer-term keeping -
these are backups of dev repos in the form of git stash commits including
untracked files.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800