Re: [PATCH] prune: --expire=time

From: Junio C Hamano <junkio@cox.net>
Date: Jan 19, 2007, 19:18 UTC
Message-ID: <7vfya6hll3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070119104935.GA5189@moooo.ath.cx>

Matthias Lederhofer <matled@gmx.net> writes:

Show 9 quoted lines

> Shawn O. Pearce <spearce@spearce.org> wrote:
>
>> Junio C Hamano <junkio@cox.net> wrote:
>> > If this is something we would want, it might make sense if we
>> > allowed "prune --expire='1.day'" syntax ;-).
>> 
>> Yes, I agree.
>
> Here is the new version.

Thanks.

> Things I'm not sure about, any further comments/discussion?
> - default value for gc.pruneexpire
> - special value(s) for gc.pruneexpire/--expire which mean 'do not
>   check for the age', currently it is 'off'

No single timeout value can be the right timeout for everybody, so a big debate is not useful here. I think 1 day as you and Shawn did makes sense.

	git prune --expire=off

felt a bit confusing to me at the first glance. Does it turn off the expiration mechanism, retaining all cruft, or turns off the mechanism to give grace period for recent objects? The answer is obviosuly the latter as "retain all cruft" is meaningless, but still it somehow feels funny. It might be easier to explain if it was:

	git prune --expire=now

Maybe an alternative:

	git prune --retain=1.day
	git prune --retain=off

perhaps?  I dunno.

We seem to use "unsigned long" as a stand-in type for time_t in the rest of the code. I'd feel better if prune_expire was also "unsigned long". We probably should talk about making them all time_t at some point but not right now.

I was tempted to say that we might want to teach approxidate "now" (add one entry to struct special in date.c), but I do not think it is useful for this application (you want prune_expire set to zero not the time we run time(NULL)), and I do not think of any other application that wants "now".