Re: [PATCH 2/2] reflog: ignore expire-unreachable for "HEAD" reflog

From: Nicolas Pitre <nico@fluxnic.net>
Date: Apr 16, 2010, 03:07 UTC
Message-ID: <alpine.LFD.2.00.1004152237060.7232@xanadu.home>
In-Reply-To: <7vljcogot1.fsf@alter.siamese.dyndns.org>

On Thu, 15 Apr 2010, Junio C Hamano wrote:

Show 10 quoted lines

> Nicolas Pitre <nico@fluxnic.net> 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