]> git.ipfire.org Git - thirdparty/git.git/commit - rerere.c
rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved
authorJunio C Hamano <gitster@pobox.com>
Sat, 19 Aug 2017 18:43:39 +0000 (11:43 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 22 Aug 2017 21:51:02 +0000 (14:51 -0700)
commit6e96cb5286105bbcf19d5c47e45334ef9a75d09d
treef9baa8d520f35b823146ff8947e7716ae843d665
parent5ea82279c066f51d446b344e82492a3554409d7d
rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved

These two configuration variables are described in the documentation
to take an expiry period expressed in the number of days:

    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.

    gc.rerereUnresolved::
    Records of conflicted merge you have not resolved are
    kept for this many days when 'git rerere gc' is run.
    The default is 15 days.

There is no strong reason not to allow a more general "approxidate"
expiry specification, e.g. "5.days.ago", or "never".

Rename the config_get_expiry() helper introduced in the previous
step to git_config_get_expiry_in_days() and move it to a more
generic place, config.c, and use date.c::parse_expiry_date() to do
so.  Give it an ability to allow the caller to tell among three
cases (i.e. there is no "gc.rerereResolved" config, there is and it
is correctly parsed into the *expiry variable, and there was an
error in parsing the given value).  The current caller can work
correctly without using the return value, though.

In the future, we may find other variables that only allow an
integer that specifies "this many days" or other unit of time, and
when it happens we may need to drop "_days" suffix from the name of
the function and instead pass the "scale" value as another parameter.

But this will do for now.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/config.txt
config.c
config.h
rerere.c
t/t4200-rerere.sh