Re: [PATCH v2] rerere: keep a background gc from killing a rebase

Hi Junio,

On 04/09/2026 19:06, Junio C Hamano wrote:

Phillip Wood [off-list ref] writes:

quoted

Overall, this commit message is rather long and it would be helpful if
you could distill it to remove unnecessary and unrelated details.

Hear hear.

The v3 log message is down to 23 lines from 81:

  [ref]

When there is somebody holding the lock, they acquired the lock
exactly because they did not want to see others (including
ourselves) to touch the rerere database until they are done.

That caught one more case I got wrong in v3. The rerere_clear() that
--abort and --skip run also waits and then goes on, and that leaves
MERGE_RR behind. The next rerere run then takes each path in it as
resolved by the user and records whatever the reset left there. The
clear is the first thing --abort and --skip do, so I'll let it fail
like "git rerere clear" does, from every caller. That also drops the
flag from rerere_clear() and rerere_forget() again and leaves am.c
and rebase.c untouched.

What makes `git rerere gc` different among all is not that it does
not retry.  It just does not insist doing a GC and instead leaves
without doing anything (and without failing).

Right, and I'll say it that way in the config text. All of them wait
for the lock except the gc, which loses nothing by giving up at once.
When the time is up, "git rerere", "git rerere forget" and "git
rerere clear" fail, and a merge or commit that would record or reuse
a resolution on the way warns and goes on without it.

quoted

A background job that the user did not explicitly start printing to the
terminal is rather confusing as it is likely to get mixed in with the
output of whatever is running in the foreground.

Very good point.

I don't think it can happen, though. The detached run has no
terminal: daemonize() reopens the standard descriptors on /dev/null
before the gc runs. Where it doesn't detach, on Windows or with
autoDetach off, the command that started it waits for it, so it
isn't in the background either. The warning a user sees comes from
the command in the foreground, once it has given up waiting.

I'll wait for the rest of the v3 comments before rerolling.

Thanks,
Thomas