Re: [PATCH 16/33] t3210: test for spurious error messages for dangling packed refs

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Apr 17, 2013, 08:11 UTC
Message-ID: <516E5938.6040704@alum.mit.edu>
In-Reply-To: <7vip3mhxhq.fsf@alter.siamese.dyndns.org>

On 04/17/2013 01:22 AM, Junio C Hamano wrote:

Show 19 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> would be that it expires *everything*.  But in fact it seems to only
>> expire things that are at least one second old, which doesn't seem at
>> all useful in the real world.  "--expire=all" is accepted without
>> complaint but doesn't do what one would hope.
> 
> Perhaps that is worth fixing, independent of this topic.
> 
> Approxidate gives the current time for anything it does not
> understand, and that is how --expire=all is interpreted as "anything
> older than now".  For that matter, even a string "now" has long been
> interpreted as the current time with the same "I do not understand
> it, so I'll give you the current timestamp" logic, until we added an
> official support for "now" at 93cfa7c7a85e (approxidate_careful()
> reports errorneous date string, 2010-01-26) for entirely different
> reasons.
> 
> A completely untested patch for your enjoyment...

I enjoy it :-) But it would be better to put the the function in the date module ("approxidate_expiry_careful()"?) and also use it from other places where an expiry date is being parsed, like

    prune --expire=<date>
    reflog expire --expire=<date>/--expire-unreachable=<date>
    gc --prune=<date>

(maybe there are others). And the special values "all" etc. would need to be documented.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/