Matthias Lederhofer <matled@gmx.net> writes:

quoted text
> 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.

quoted text
> 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".

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html