On Thu, Apr 24, 2008 at 1:09 AM, Russ Dill <russ.dill@xxxxxxxxx> wrote: > On Wed, Apr 23, 2008 at 4:13 PM, Haakon Riiser <haakon.riiser@xxxxxxxxxx> 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@xxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
