unannex: Commit staged changes at end

to avoid some confusing behavior with the pre-commit hook, which would see
some types of commits after an unannex as checking in of an unlocked file.

5 files changed, 23 insertions, 6 deletions

diff --git a/Command/Unannex.hs b/Command/Unannex.hs
index 413443969..3810cca1c 100644
--- a/Command/Unannex.hs
+++ b/Command/Unannex.hs
@@ -55,5 +55,10 @@ cleanup file key = do
 
 	fromAnnex key file
 	logStatus key ValueMissing
-
+	
+	-- Commit staged changes at end to avoid confusing the
+	-- pre-commit hook if this file is later added back to
+	-- git as a normal, non-annexed file.
+	Annex.queue "commit" ["-m", "content removed from git annex"] "--"
+	
 	return True
diff --git a/debian/changelog b/debian/changelog
index d7edc1733..6bfc94644 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ git-annex (0.20) UNRELEASED; urgency=low
   * Preserve specified file ordering when instructed to act on multiple
     files or directories. For example, "git annex get a b" will now always
     get "a" before "b". Previously it could operate in either order.
+  * unannex: Commit staged changes at end, to avoid some confusing behavior
+    with the pre-commit hook, which would see some types of commits after
+    an unannex as checking in of an unlocked file.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 31 Jan 2011 20:06:02 -0400
 
diff --git a/doc/bugs/unannex_vs_unlock_hook_confusion.mdwn b/doc/bugs/unannex_vs_unlock_hook_confusion.mdwn
index 7e4a9f291..c03990c20 100644
--- a/doc/bugs/unannex_vs_unlock_hook_confusion.mdwn
+++ b/doc/bugs/unannex_vs_unlock_hook_confusion.mdwn
@@ -11,3 +11,5 @@ and has been re-added as a normal file, vs an unlocked file? --[[Joey||
 > Hmm, not really. An unannexed file's content will have been dropped from
 > the backend, but that's about the only difference. Perhaps unannex should
 > just commit the removal of the file itself? --[[Joey]]
+
+> [[done]], staged changes committed at end.
diff --git a/doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment b/doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment
index 548f7aacb..9f3223578 100644
--- a/doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment
+++ b/doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment
@@ -8,5 +8,9 @@ Sorry for all the followups, but I see now that if you unannex, then add the fil
 
 This seems to be a bug. git-annex's hook thinks that you have used git annex unlock (or \"git annex edit\") on the file and are now committing a changed version, and the right thing to do there is to add the new content to the annex and update the symlink accordingly. I'll track this bug over at [[bugs/unannex_vs_unlock_hook_confusion]].
 
-So, committing after unannex, and before checking the file into git in the usual way, is a workaround.
+So, committing after unannex, and before checking the file into git in the
+usual way, is a workaround. But only if you do a "git commit" to commit
+staged changes.
+
+Anyway, this confusing point is fixed in git now!
 """]]
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 83a286b0e..68a1672df 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -156,10 +156,13 @@ Many git-annex commands will stage changes for later `git commit` by you.
 
 * unannex [path ...]
 
-  Use this to undo an accidental add command. This is not the command you
-  should use if you intentionally annexed a file and don't want its contents
-  any more. In that case you should use `git annex drop` instead, and you
-  can also `git rm` the file.
+  Use this to undo an accidental `git annex add` command. You can use
+  `git annex unannex` to move content out of the annex at any point,
+  even if you've already committed it.
+
+  This is not the command you should use if you intentionally annexed a
+  file and don't want its contents any more. In that case you should use
+  `git annex drop` instead, and you can also `git rm` the file.
 
 * uninit