Re: approxidate woes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 15, 2018 at 02:45:28PM +0100, Andreas Krey wrote:

> I've now located why our backup repo shrinks every month:
> 
>   git gc --prune=2d
> 
> doesn't do what I expected, and differs a lot from --prune=48h.

Yeah, it understands "2 days", but not "d" as a unit.

I don't think "48h" does what you expect either:

  $ t/helper/test-date approxidate now
  now -> 2018-11-15 14:43:32 +0000

  $ t/helper/test-date approxidate 48h
  48h -> 2018-11-15 14:43:34 +0000

  $ t/helper/test-date approxidate 48.hours
  48.hours -> 2018-11-13 14:43:38 +0000

It might be reasonable to teach approxidate these obvious shorthands
(one tricky one is "m"; normally I'd say "minute", but in Git timescales
"month" is more likely).

> Mildly irritating, and worse, hard to find in the documentation.
> I failed at the latter and fell back to the sources, finding
> './bin-wrappers/test-date approxidate' for trying.
> 
> Where would I look?

I don't think approxidate is really documented at all. It started as
Linus's idea of "handle what people would probably say", and the fixes
over the years have mostly been "eh, that's crazy, let's do better with
this input".

You'd have to reverse engineer it a bit from the source, unfortunately.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux