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

From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <derrickstolee@github.com>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>,
	"Taylor Blau" <me@ttaylorr.com>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: tb/cruft-packs (was Re: What's cooking in git.git (Mar 2022, #01; Thu, 3))
Date: Mon, 07 Mar 2022 13:34:57 -0800	[thread overview]
Message-ID: <xmqqpmmxqwe6.fsf@gitster.g> (raw)
In-Reply-To: <332f9b54-edfb-50e7-46a7-2e46d3b574e4@github.com> (Derrick Stolee's message of "Mon, 7 Mar 2022 15:51:40 -0500")

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.

Have we broken that over the course of adding new commits and
developers?  If so, we have stuff that needs fixing, and also ensure
that the developer and end-user expectations are aligned.

Thanks.