Taylor Blau <me@xxxxxxxxxxxx> 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.
