public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox•com>
To: Uwe Hausbrand <uwe.hausbrand@gmx•de>
Cc: git@vger•kernel.org
Subject: Re: fatal: bad numeric config value '60 days' for 'gc.rerereresolved': invalid unit
Date: Fri, 21 Jul 2017 07:33:31 -0700	[thread overview]
Message-ID: <xmqqfudpj1vo.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAHNyMp8xeye8EvtOdrX34QVCDsBCu3aLQVdyGRTVqyHXjZ4FFQ@mail.gmail.com> (Uwe Hausbrand's message of "Fri, 21 Jul 2017 14:59:52 +0200")

Uwe Hausbrand <uwe.hausbrand@gmx•de> writes:

> seems like there is a bug with "git rerere gc" not understanding grace
> periods like "60 days" defined in the config.
>
> What I did:
>
> git config gc.rerereresolved "60 days"

Let's see how the variable is explained in the documentation.

    gc.rerereResolved::
            Records of conflicted merge you resolved earlier are
            kept for this many days when 'git rerere gc' is run.
            The default is 60 days.  See linkgit:git-rerere[1].

Notice that "for this many days" tries to (and probably
unsuccessfully) tell you that this variable is expected to be set to
an integer [*1*], counted in "days".  IOW, you'd want "60" instead.

Having said that, it may not be a bad idea to enumerate these
"expected to be an integer that counts in some unit" variables that
are described in a similar way (i.e. look for "this many" in
Documentation/config.txt), and then for each of them that could be
counted in different unit (e.g. it is not outrageously wrong to
expect that you could specify that rerere records that are older
than 3 months are expired):

 - decide what kind of quantity the variable specifies (e.g. "this
   many days" and "this many seconds" variables are giving a
   "timeperiod").

 - keep the code that reacts to an integer without any unit to
   behave the same (e.g. "[gc] rerereresolved = 30" will keep
   meaning "30 days");

 - extend the code so that when the value given is not an integer,
   it tries to parse it as a specification for the expected quantity
   (e.g. "this many days" and "this many seconds" variables would
   understand if you said "60 days" or "2 months")


[Footnote]

 *1* I think we actually expect a scaled integer whenever we expect
     an integral value, so you probably could say "6k" to specify
     "6,000 days"; "days" not being any of the recognised unit
     suffix like k, M, G, etc. is where "invalid unit" comes from.

  parent reply	other threads:[~2017-07-21 14:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 12:59 fatal: bad numeric config value '60 days' for 'gc.rerereresolved': invalid unit Uwe Hausbrand
2017-07-21 14:30 ` Martin Ågren
2017-07-21 14:33 ` Junio C Hamano [this message]
2017-07-21 17:35   ` Uwe Hausbrand
2017-08-19 20:30   ` [PATCH 0/2] accept non-integer for "this many days" expiry specification Junio C Hamano
2017-08-19 20:30     ` [PATCH 1/2] rerere: represent time duration in timestamp_t internally Junio C Hamano
2017-08-19 20:30     ` [PATCH 2/2] rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved Junio C Hamano
2017-08-20 21:45       ` Ramsay Jones
2017-08-21  0:20         ` Junio C Hamano
2017-08-22 21:46     ` [PATCH v2 0/6] accept non-integer for "this many days" expiry specification Junio C Hamano
2017-08-22 21:46       ` [PATCH v2 1/6] t4200: give us a clean slate after "rerere gc" tests Junio C Hamano
2017-08-22 21:46       ` [PATCH v2 2/6] t4200: make "rerere gc" test more robust Junio C Hamano
2017-08-22 21:46       ` [PATCH v2 3/6] t4200: gather "rerere gc" together Junio C Hamano
2017-08-22 21:46       ` [PATCH v2 4/6] t4200: parameterize "rerere gc" custom expiry test Junio C Hamano
2017-08-22 21:46       ` [PATCH v2 5/6] rerere: represent time duration in timestamp_t internally Junio C Hamano
2017-08-22 21:46       ` [PATCH v2 6/6] rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqfudpj1vo.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=uwe.hausbrand@gmx$(echo .)de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox