Re: Re*: Extremely slow progress during 'git reflog expire --all'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 07, 2010 at 11:39:15AM -0700, Junio C Hamano wrote:

> Actually I do; I think it breaks correctness a big way (the second
> paragraph of the proposed log message of the following).
> [...]
> However, it is a different matter if a commit is _not_ known to be
> reachable and the commit is known to be unreachable.  Because you can
> rewind a ref to an ancient commit and then reset it back to the original
> tip, a recent reflog entry can point at a commit that older than the
> expire-total timestamp and we shouldn't expire it.  For that reason, we
> had to run merge-base computation when a commit is _not_ known to be
> reachable.

Oh, right. Didn't I even mention that case earlier in the thread? I was
just being dumb. Or maybe I was pretending to be dumb, so that I could
trick you into writing the patch. Who knows?

> [patch]

Patch looked fine from my reading. I no longer have Frans' gigantic test
repo available, though, so I can't test whether it fixes the problem
(but I'm pretty sure it must from my earlier analysis).

-Peff
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]