comment
authorJoey Hess <joeyh@joeyh.name>
Wed, 14 May 2025 17:25:24 +0000 (13:25 -0400)
committerJoey Hess <joeyh@joeyh.name>
Wed, 14 May 2025 17:25:24 +0000 (13:25 -0400)
doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_2_c3d2b08246f2c92ef3354d25990c22c3._comment [new file with mode: 0644]

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 (file)
index 0000000..5ddab5c
--- /dev/null
@@ -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.
+"""]]