Re: BUG: Race condition due to reflog expiry in "gc"
- Date: Wed, 13 Mar 2019 10:43:57 +0900
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: BUG: Race condition due to reflog expiry in "gc"
Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> I'm still working on fixing a race condition I encountered in "gc"
> recently, but am not 100% sure of the fix. So I thought I'd send a
> braindump of what I have so far in case it jolts any memories.
> The problem is that when we "gc" we run "reflog expire --all". This
> iterates over the reflogs, and takes a *.lock for each reference.
> It'll fail intermittendly in two ways:
> 1. If something is concurrently committing to the repo it'll fail
> because we for a tiny amount of time hold a HEAD.lock file, so HEAD
> can't be updated.
> 2. On a repository that's just being "git fetch"'d by some concurrent
> process the "gc" will fail, because the ref's SHA1 has changed,
> which we inspect as we aquire the lock.
Both sounds very much expected and expectable outcome. I am not
sure how they need to be called bugs.