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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
