Re: tb/cruft-packs (was Re: What's cooking in git.git (Mar 2022, #01; Thu, 3))

From: Taylor Blau <me@ttaylorr.com>
Date: Mar 8, 2022, 00:52 UTC
Message-ID: <Yiao1+Zdlj9zZgCQ@nand.local>
In-Reply-To: <xmqqpmmxqwe6.fsf@gitster.g>

On Mon, Mar 07, 2022 at 01:34:57PM -0800, Junio C Hamano wrote:

Show 14 quoted lines

> Derrick Stolee <derrickstolee@github.com> writes:
>
> > ... Git does not
> > support parallel writers doing significant updates like full
> > repacks and GCs and instead relies on the user to control the
> > concurrency there.
>
> At least when we set out to give our users Git, allowing such
> concurrent writing without corrupting repositories was what we aimed
> to achieve.  If you did two simultanenous repacks, one of the may
> fail while trying to acquire a lock or two, so from waste-avoidance
> perspective, there is a strong incentive on the user's side to make
> sure such housecleaning tasks are not triggered needlessly and
> simultanously, but it shouldn't lead to repository corruption.

It is not true that `git repack` does not support parallel writers.

Indeed, `repack` doesn't hold any locks on the repository ahead of time, but the concurrent writers situation will at worst leave us in a state where objects appear twice across multiple packs.

So yes, users are incentivized to limit multiple repack processes from stomping on each other and wasting effort, but multiple writers running `git repack` cannot corrupt a repository.

Thanks, Taylor