From: Nicolas Pitre Date: Fri, 16 Apr 2010 03:07:43 GMT Subject: Re: [PATCH 2/2] reflog: ignore expire-unreachable for "HEAD" reflog Message-ID: In-Reply-To: <7vljcogot1.fsf@alter.siamese.dyndns.org> On Thu, 15 Apr 2010, Junio C Hamano wrote: > Nicolas Pitre writes: > > > Again, keeping reflogs 90 days for stuff that is _already_ reachable > > through existing refs is much less useful than keeping otherwise > > unreachable stuff 90 days. So I still don't see the point of this > > eagerness to prune deleted stuff faster. > > Hmph, I honestly cannot care about this very much without knowing where > this is going, because the distinction between the two has been with us > practically forever, since the day one of "reflog expire". Argh. OK you can paint me confused. I was mixing up --expire-unreachable with --stale-fix. Having my head screwed back on now, I do agree with Jeff when he says: |I think another way of addressing the same problem would be to redefine |"reachable" in this context as "reachable from any current ref". Otherwise having a special exception for HEAD would effectively make those unreachable objects non prunable until the HEAD reflog entries are themselves expired. > Is there any constructive conclusion you are aiming for? For example, is > a proposal to update the default value of both to 90 or 120 days coming? I think that the default value for reflogexpireunreachable should be the value of reflogexpire, and not 30 days. In my opinion, having a shorter expiration period for non reachable objects by default makes little sense. Again, it is for the non reachable objects that the reflog is most useful. Nicolas