David Tweed <david.tweed@xxxxxxxxx> wrote: > 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. Although that's certainly true, the original poster was asking about `git commit --amend`. In such a case the reflog for HEAD and the current branch are going to anchor the old commit for the reflog expire period, which is 90 days. Way longer than the 2 week aging of loose objects. -- Shawn. -- 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
