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

Taylor Blau [off-list ref] writes:

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.