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

[Taylor Blau <me@ttaylorr.com>]

On Mon, Mar 07, 2022 at 01:34:57PM -0800, Junio C Hamano wrote:
> 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