Uwe Hausbrand <uwe.hausbrand@xxxxxx> 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.
