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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 9, 2021, 22:11 UTC
Message-ID: <xmqq35z9g3pw.fsf@gitster.c.googlers.com>
In-Reply-To: <X/ipCPFyW3gAWrHo@nand.local>

Taylor Blau <me@ttaylorr.com> writes:

Show 8 quoted lines

> Here, I think the issue is less complicated. Since you're cloning from a
> local repository, the 'git clone' command calls 'clone_local()', which
> in turn calls 'copy_or_link_directory()'. If the directory being copied
> changes while being iterated over, the receiving end isn't guaranteed to
> pick up the changes.
>
> Worse, if the source _removes_ a file that hasn't yet been copied, over,
> then the copy will fail, which is what you're seeing here.

And the source that removes a file during a repack would create a new file to keep the contents of the removed file available (if the object still matters after the repack), but because we do not retry our "cp -r" equivalent used in the clone_local(), we may not pick such a new file up.

So, we probalby should document "git clone --local" that the user should expect fallout similar to what may happen when they copy a directory hierarchy with "cp -r src dst" and muck with what is in "src" while the copy is ongoing.