Matthias Lederhofer <matled@xxxxxxx> writes: > Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > >> Junio C Hamano <junkio@xxxxxxx> 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". - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html