Re: Cleaning the .git directory with gc
- From
- David Tweed <david.tweed@gmail.com>
- Date
- Apr 24, 2008, 00:32 UTC
- Message-ID
- <e1dab3980804231732x29d6d73cudd0568a910642639@mail.gmail.com>
- In-Reply-To
- <f9d2a5e10804231709v1d7e426fwf68b3d316a15081a@mail.gmail.com>
On Thu, Apr 24, 2008 at 1:09 AM, Russ Dill <russ.dill@gmail.com> wrote:
Show 8 quoted lines
> On Wed, Apr 23, 2008 at 4:13 PM, Haakon Riiser <haakon.riiser@fys.uio.no> wrote: > > I've recently started using git, and while experimenting with > > git commit --amend, I noticed that git gc does not do what I > > expected. Example: > > Thats a lot of work without first reading the man page: > > --prune
[snip]
There's a relatively recent change in this area. Git keeps stuff that's apparently unattached for a period of, by default, 2 weeks (determined by gc.pruneexpire variable) after which a git gc will remove it. The reasoning is that even with the careful design of the git updating strategy there are rare times when with a concurrent other git process there are files in the repo that look unattached but will become attached as the other process completes. Files kept this way aren't propagated by clones or pulls so they're essentially invisible to everything else. If you're sure you can force removal with
git prune --expire now
AFAICS there's no way to call "git gc --prune" with an --expire option so you've got to use the "git prune" command.
HTH
-- cheers, dave tweed__________________________ david.tweed@gmail.com Rm 124, School of Systems Engineering, University of Reading. "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot