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

On Sat, Jan 09, 2021 at 02:11:55PM -0800, Junio C Hamano wrote:

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.

Mm, good idea. Below the cut line is a patch to do just that. I thought
briefly about documenting it in the pack-protocol page, but it only
mentions the local transport in passing, so it seemed inappropriate to
add that much more detail there.

--- 8< ---

Subject: [PATCH] Documentation/git-clone.txt: document race with --local

When running 'git clone --local', the operation may fail if another
process is modifying the source repository. Document that this race
condition is known to hopefully help anyone who may run into it.

Suggested-by: Junio C Hamano <redacted>
Signed-off-by: Taylor Blau <redacted>
---
 Documentation/git-clone.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 876aedcd47..02d9c19cec 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt

@@ -57,6 +57,10 @@ repository is specified as a URL, then this flag is ignored (and we
 never use the local optimizations).  Specifying `--no-local` will
 override the default when `/path/to/repo` is given, using the regular
 Git transport instead.
++
+*NOTE*: this operation can race with concurrent modification to the
+source repository, similar to running `cp -r src dst` while modifying
+`src`.

 --no-hardlinks::
 	Force the cloning process from a repository on a local
--

2.30.0.138.g6d7191ea01