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

From: Thomas Bachem <mail@thomasbachem.com>
Date: Sep 4, 2026, 18:17 UTC
Message-ID: <CAA0xjtr4sDyrkf8VJz3CUBGVvc7LdGhOb1K9kgdskhD+_hbSwQ@mail.gmail.com>
In-Reply-To: <xmqqfqzp3q10.fsf@gitster.g>

Hi Junio,

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

Show 6 quoted lines

> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>> 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:

  <pull.2214.v3.git.1788537081930.gitgitgadget@gmail.com>

> 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.

Show 5 quoted lines

>> 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