Added a comment

1 files changed, 39 insertions, 0 deletions

diff --git a/doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_5_2ea1d78ec8a652a53391969e43bcb6f0._comment b/doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_5_2ea1d78ec8a652a53391969e43bcb6f0._comment
new file mode 100644
index 000000000..72495fe66
--- /dev/null
+++ b/doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_5_2ea1d78ec8a652a53391969e43bcb6f0._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 5"
+ date="2014-10-10T00:01:54Z"
+ content="""
+Actually, the pre-commit hook does stage the annexed symlink into the index. But it seems that `git commit $file` causes the pre-commit hook's changes to the index to be partially ignored, in a way that `git commit -a` does not.
+
+While the pre-commit hook is running, `git commit -a` sets `GIT_INDEX_FILE=index.lock`, while `git commit $file` instead sets `GIT_INDEX_FILE=next-index-$pid.lock`. git's builtin/commit.c refers to this latter file as the \"false index\". Full comment from git:
+
+<pre>
+        /*
+         * A partial commit.
+         *
+         * (0) find the set of affected paths;
+         * (1) get lock on the real index file;
+         * (2) update the_index with the given paths;
+         * (3) write the_index out to the real index (still locked);
+         * (4) get lock on the false index file;
+         * (5) reset the_index from HEAD;
+         * (6) update the_index the same way as (2);
+         * (7) write the_index out to the false index file;
+         * (8) return the name of the false index file (still locked);
+         *
+         * The caller should run hooks on the locked false index, and
+         * create commit from it.  Then
+         * (A) if all goes well, commit the real index;
+         * (B) on failure, rollback the real index;
+         * In either case, rollback the false index.
+         */
+
+</pre>
+
+So, the pre-commit hook is run on the false index, which has been reset to HEAD. The changes it stages are committed, but do not affect the real index. If I read that comment right, the commit from the false index is then supposed to be committed on the real index, but it seems in this case the real index does not get updated to reflect the changes.
+
+This seems to be a bug in git. Reproduced w/o git-annex, and bug report sent to the git ML.
+
+Depending on what happens, this might just get fixed in git. Or, I might need to make git-annex detect this case (by looking at what `GIT_INDEX_FILE` is set to) and have the pre-commit hook cancel the commit.
+"""]]