Re: git gc taking forever to reflog expire --all
- From
Jeff King <peff@peff.net>
- Date
- May 11, 2010, 15:30 UTC
- Message-ID
- <20100511153048.GA17974@coredump.intra.peff.net>
- In-Reply-To
- <3924516F-2626-41C0-8648-47A9481FA09F@adacore.com>
[for those reading the list, Geert was kind enough to send me a copy off his repo off-list. Here's what I found.]
On Tue, May 11, 2010 at 06:05:14AM -0400, Geert Bosch wrote:
Show 7 quoted lines
> > There are some corner cases that can cause the expire-unreachable > > algorithm to behave badly. The fix is b4ca1db (reflog > > --expire-unreachable: avoid merge-base computation, 2010-04-07), but > > hasn't been included in a release yet. > > > I tried with v1.7.1 + cherry-pick b4ca1db968eb57d9cd869337bffa254e0b2c83bd, > but that didn't solve the issue.
Are you absolutely sure you weren't accidentally running an older version of git? I was able to reproduce your problem with git v1.7.0, but current 'master' fixes it. I bisected and ended up at b4ca1db.
There is the possibility that cherry-picking b4ca1db isn't sufficient for some reason, but I didn't see any related commits that would make a difference. In either case, your problem is just another manifestation of the same issue, so it should be taken care of in v1.7.2.
Show 6 quoted lines
> > In the meantime, you can work around it with: > > > > git config gc.reflogExpireUnreachable never > > I had tried that too, but I guess I'll just have to be very patient: > 22707 ttys001 11:14.27 git reflog expire --all
Sorry, this was my fault. Apparently the "never" token had a bug which was fixed in v1.7.0.3. If the git you were testing on was before that, then it would have done nothing.
-Peff