Hi,
Jonathan Tan wrote:
> In a087cc9819 ("git-gc --auto: protect ourselves from accumulated
> cruft", 2007-09-17), the user was warned if there were too many
> unreachable loose objects. This made sense at the time, because gc
> couldn't prune them safely. But subsequently, git prune learned the
> ability to not prune recently created loose objects, making pruning able
> to be done more safely, and gc was made to automatically prune old
> unreachable loose objects in 25ee9731c1 ("gc: call "prune --expire
> 2.weeks.ago" by default", 2008-03-12).
>
> This makes the warning unactionable by the user, as any loose objects
> left are not deleted yet because of safety, and "git prune" is not a
> command that the user is recommended to run directly anyway.
I agree that given the better alternatives we have now, "git prune" is
not such a great option these days. E.g. should it say
struct strbuf now = STRBUF_INIT;
date_stamp(&now);
...
"run 'git gc --prune=%s' to remove them", now.buf);
?
> This was noticed when a daemonized gc run wrote this warning to the log
> file, and returned 0; but a subsequent run merely read the log file, saw
> that it is non-empty and returned -1 (which is inconsistent in that such
> a run should return 0, as it did the first time).
Here's a series to address that motivating case. Thanks for the
careful analysis and to Peff for the patient explanations.
Sincerely,
Jonathan Nieder (3):
gc: improve handling of errors reading gc.log
gc: exit with status 128 on failure
gc: do not return error for prior errors in daemonized mode
Documentation/config.txt | 3 ++-
builtin/gc.c | 53 ++++++++++++++++++++++++++--------------
t/t6500-gc.sh | 6 ++---
3 files changed, 40 insertions(+), 22 deletions(-)
