Re: 'git gc auto' didn't trigger on large reflog

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

 



Patrick Steinhardt <ps@xxxxxx> writes:

> No, there isn't, and computing it is also potentially expensive. You
> basically have to iterate through each reflog and then also iterate
> through all of its reflog entries to figure out whether anything needs
> cleaning or not.
>
> But probably we can come up with clever heuristics instead that don't
> require us to be this thorough. We could for example just read the
> "HEAD" reflog and figure out whether it contains reflog entries that
> would be pruned.

As we should be able to "seek" to implement HEAD@{2.months.ago}, I'd
imagine that we should be able to ask "give me the oldest entry in
your log" to a ref.  Ask that question to a handful of refs that
have been most recently modified (with the theory that a ref that is
more often modified is also likely to have been touched in the
recent past---your HEAD heuristics is a good approximation), and we
learn fairly cheaply if it is likely that we have entries to be
expired.




[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]

  Powered by Linux