Re: [RFC] git gc "--prune=now" semantics considered harmful

On Fri, Jun 1, 2018 at 2:04 AM Jeff King wrote: > > We'd also accept relative times like "5.minutes.ago" (in fact, the > default is a relative 2.weeks.ago, though it's long enough that the > difference between "2 weeks" and "2 weeks plus 5 minutes" may not matter > much). So we probably ought to

Re: [RFC] git gc "--prune=now" semantics considered harmful

On Sun, May 27, 2018 at 08:31:14AM +0900, Junio C Hamano wrote: > > So I actually would much prefer that foir git gc, "--prune=now" means > > > > (a) "now" > > > > (b) now at the _start_ of the "git gc" operation, not the time at > > the _end_ of the operation when we've already spent a

Re: [RFC] git gc "--prune=now" semantics considered harmful

On Sat, May 26, 2018 at 4:31 PM Junio C Hamano wrote: > *That* is something I don't do. After all, I am fully aware that I > have started end-of-day ritual by that time, so I won't even look at > a new patch (or a pull request for that matter). Sounds like you're more

Re: [RFC] git gc "--prune=now" semantics considered harmful

Linus Torvalds writes: > Soes my use pattern of "git gc --prune=now" make sense? Maybe not. But > it's what I've gotten used to, and it's at least not entirely insane. FWIW, my end-of-day ritual is to do repack -a -d -f with a large window and a small depth,

[RFC] git gc "--prune=now" semantics considered harmful

So this is a RFC patch, I'm not sure how much people really care, but I find the current behavior of "git gc --prune=now" to be unnecessarily dangerous. There's two issues with it: (a) parse_expiry_date() considers "now" to be special, and it actually doesn't mean "now" at all, it means