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

[Nicolas Pitre <nico@fluxnic.net>]

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

> 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