Re: suspected race between packing and fetch (single case study)

[Taylor Blau <me@ttaylorr.com>]

On Tue, Jan 12, 2021 at 12:46:22PM -0500, yoh@onerussian.com wrote:
>
> On Mon, 11 Jan 2021, Taylor Blau wrote:
> > ++
> > +*NOTE*: this operation can race with concurrent modification to the
> > +source repository, similar to running `cp -r src dst` while modifying
> > +`src`.
>
> Couldn't `gc` be triggered by git in seemingly read-only operations,
> thus possibly ruining the analogy with `cp` while doing `rm` (explicit
> intent to modify)?
>
> Moreover, situation is also a bit different since a sane user script
> would not place `rm` into background to keep operating on original
> source right before doing `cp` -- and that is what is happening here:

If you're suggesting that something is missing from the above patch, I'm
not sure I quite understand what you would like added.

All of these (background gc, explicit rm-ing) fall under the category of
"concurrent modification": they are changing the source directory in
some way while a read operation is taking place.

> `git` operation is presumably complete (but leaves `gc` running in the
> background) and script advances to the next step only to run into a race
> condition with that preceding `git` command which apparently triggered
> `gc`.  Should then any script which operates on local `git` repositories
> not to forget to add   -c gc.autodetach=0  for every git
> invocation which might be potentially effected?

If your workflow is that you are frequently cloning via the local
transport and there is no other synchronization going on between
whatever work is happening in the source repository, then yes. (But note
of course that you can set gc.autodetach=0 via the source repository's
.git/config rather than typing it each time).

Thanks,
Taylor