From b4e5f2b8a4a8d72886c3b049243788578b3509e1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 7 Apr 2023 12:52:43 -0400 Subject: [PATCH] response --- ...t_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/forum/Batch_process__44___git_rm__44___and_locking/comment_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment diff --git a/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment b/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment new file mode 100644 index 0000000000..39a1edf016 --- /dev/null +++ b/doc/forum/Batch_process__44___git_rm__44___and_locking/comment_1_6cb866b48f6426e7ecc4f8d6af5b710d._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2023-04-07T16:42:16Z" + content=""" +The lock you need to worry about here is for `.git/index`, +which both `git rm` and `git-annex addurl` need to modify +(when the latter is adding new files, not adding urls to existing files). +Unfortunately git's handling of that lock file doesn't play well with multiple +processes (unlike git-annex's other lock files that it uses). + +With --batch, git-annex reads a line, handles it, outputs a response, and +waits for the next line. It should not keep any lock held while it's +waiting for the line. So, you should be able to schedule your `git rm` +to happen at that point and not have problems with locks colliding. +"""]] -- 2.30.2