From 0646eabc17027d6c4d229068d11c33d64774a0fb Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 14 May 2025 13:25:24 -0400 Subject: [PATCH] comment --- ..._2_c3d2b08246f2c92ef3354d25990c22c3._comment | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_2_c3d2b08246f2c92ef3354d25990c22c3._comment diff --git a/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_2_c3d2b08246f2c92ef3354d25990c22c3._comment b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_2_c3d2b08246f2c92ef3354d25990c22c3._comment new file mode 100644 index 0000000000..5ddab5ce5d --- /dev/null +++ b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_2_c3d2b08246f2c92ef3354d25990c22c3._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2025-05-14T17:05:37Z" + content=""" +It's pretty easy to replicate this behavior: + + cat > .git/index.lock + +And while that process is still running, start the assistant. + +It might be some other ".lock" file or perhaps `.git/gc.pid` that a process +has open for write. The assistant does not want to start running with a +stale git lock file, which is a pretty common problem given the way that +git lock files work. So when the lock file exists, it waits for it to have +no writers, before removing it. +"""]]