unannex: Refuse to unannex when repo is too new to have a HEAD

In this case there must be staged changes in the index (if there is
anything to unannex), and the unannex code path needs to run with a clean
index.

Command/Unannex.hs

@@ -53,11 +53,14 @@ wrapUnannex a = ifM isDirect
 		, Param "--no-verify"
 		, Param "-m", Param "content removed from git annex"
 		]
-	cleanindex = do
-		(diff, cleanup) <- inRepo $ DiffTree.diffIndex Git.Ref.headRef
-		if null diff
-			then void (liftIO cleanup) >> return True
-			else void (liftIO cleanup) >> return False
+	cleanindex = ifM (inRepo Git.Ref.headExists)
+		( do
+			(diff, cleanup) <- inRepo $ DiffTree.diffIndex Git.Ref.headRef
+			if null diff
+				then void (liftIO cleanup) >> return True
+				else void (liftIO cleanup) >> return False
+		, return False
+		)
 
 start :: FilePath -> Key -> CommandStart
 start file key = stopUnless (inAnnex key) $ do

debian/changelog

@@ -7,6 +7,10 @@ git-annex (5.2015022) UNRELEASED; urgency=medium
   * fsck: Multiple incremental fscks of different repos (including remotes)
     can now be running at the same time in the same repo without it
     getting confused about which files have been checked for which remotes.
+  * unannex: Refuse to unannex when repo is too new to have a HEAD,
+    since in this case there must be staged changes in the index
+    (if there is anything to unannex), and the unannex code path
+    needs to run with a clean index.
 
  -- Joey Hess <id@joeyh.name>  Thu, 19 Feb 2015 14:16:03 -0400
 

doc/bugs/unannex_requires_commit_for_new_directories.mdwn

@@ -28,3 +28,4 @@ git-annex: Cannot proceed with uncommitted changes staged in the index. Recommen
 ### What version of git-annex are you using? On what operating system?
 The issue occurs with last version of git-annex, available at the time of this post (2015-02-19 16:20). I could reproduce the issue in all other versions of git-annex I tried (not many though). I am using Linux, Ubuntu 12.04 amd64.
 
+> [[done]]; added check for repository too new to have a HEAD. --[[Joey]]

doc/bugs/unannex_requires_commit_for_new_directories/comment_1_75814d6b4a59a4b7b950f9f2a27f0789._comment

@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-02-25T17:45:50Z"
+ content="""
+Git provides ample facilities to remove any commits that you don't like
+from your repository's history. Eg, `git reset HEAD^^`
+
+This check for a clean index was added in [[!commit 7dc680415480fbbadc5dfd37f1ce72084fb1887d]]
+which made unannex not make 1 commit per file it unannexed. That was a
+massive improvement in speed and number of commits.
+
+In order for unannex to make just 1 commit at the end, instead of 1 per
+file, it has to stage its changes in the index. Since it then needs to
+commit the index at the end, we have one reason for it to require the index
+not have staged changes, since those stages changes would get included in
+the unannex commit.
+
+I suspect I had a second reason in mind when making that change.
+The unannex commit has to be run with the pre-commit hook disabled
+for complicated reasons. Involving other changes that are not unannex
+changes in that commit would thus defeat the fixups that the pre-commit
+hook normally does to such changes. This would at least prevent annexed
+symlink path fixups from happening, and it might result in whole unlocked
+files getting their full contents unexpectedly committed to git.
+
+There is no inconsistency between new and existing directories.
+The difference is between repositories with a HEAD and repositories too
+new to have one. Maybe it's a bug that unannex doesn't refuse to run
+in a repostory too new to have a HEAD, since it cannot tell if there are
+other staged changes with no HEAD to diff against.
+"""]]