unlock: Don't allow unlocking files that have never been committed to git before

Avoids an intractable problem that prevents the pre-commit hook from
telling if such a file is intended to be an annexed file or not.

Command/Unlock.hs

@@ -10,6 +10,7 @@ module Command.Unlock where
 import Common.Annex
 import Command
 import Annex.Content
+import Annex.CatFile
 import Utility.CopyFile
 
 cmd :: [Command]
@@ -29,10 +30,10 @@ start :: FilePath -> Key -> CommandStart
 start file key = do
 	showStart "unlock" file
 	ifM (inAnnex key)
-		( ifM (checkDiskSpace Nothing key 0)
+		( ifM (isJust <$> catKeyFileHEAD file)
 			( next $ perform file key
 			, do
-				warning "not enough disk space to copy file"
+				warning "this has not yet been committed to git; cannot unlock it"
 				next $ next $ return False
 			)
 		, do
@@ -41,19 +42,24 @@ start file key = do
 		)
 
 perform :: FilePath -> Key -> CommandPerform
-perform dest key = do
-	src <- calcRepo $ gitAnnexLocation key
-	tmpdest <- fromRepo $ gitAnnexTmpObjectLocation key
-	liftIO $ createDirectoryIfMissing True (parentDir tmpdest)
-	showAction "copying"
-	ifM (liftIO $ copyFileExternal CopyAllMetaData src tmpdest)
-		( do
-			liftIO $ do
-				removeFile dest
-				moveFile tmpdest dest
-			thawContent dest
-			next $ return True
-		, do
-			warning "copy failed!"
-			next $ return False
-		)
+perform dest key = ifM (checkDiskSpace Nothing key 0)
+	( do
+		src <- calcRepo $ gitAnnexLocation key
+		tmpdest <- fromRepo $ gitAnnexTmpObjectLocation key
+		liftIO $ createDirectoryIfMissing True (parentDir tmpdest)
+		showAction "copying"
+		ifM (liftIO $ copyFileExternal CopyAllMetaData src tmpdest)
+			( do
+				liftIO $ do
+					removeFile dest
+					moveFile tmpdest dest
+				thawContent dest
+				next $ return True
+			, do
+				warning "copy failed!"
+				next $ return False
+			)
+	, do
+		warning "not enough disk space to copy file"
+		next $ return False
+	)

debian/changelog

@@ -1,3 +1,11 @@
+git-annex (5.20141232) UNRELEASED; urgency=medium
+
+  * unlock: Don't allow unlocking files that have never been committed to git
+    before, to avoid an intractable problem that prevents the pre-commit
+    hook from telling if such a file is intended to be an annexed file or not.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 02 Jan 2015 13:35:13 -0400
+
 git-annex (5.20141231) unstable; urgency=medium
 
   * vicfg: Avoid crashing on badly encoded config data.

doc/bugs/git_annex_sync_can_commit_files_to_.git__47__objects_instead_of_.git__47__annex.mdwn

@@ -2,8 +2,16 @@
 
 If you `git annex edit FILE`, an already-committed file, then do `git annex sync`, FILE will be added to .git/objects, but can be cleaned up with `git prune`. An annoyance, but not a huge problem.
 
+> This is why you're recommended to use `git add` after you're done
+> changing unlocked files. This avoids the git commit staging the file
+> in the index, even though the pre-commit hook fixes that up. It does
+> indeed leave the file contents in .git/objects, although with no refs
+> pointing to it, `git prune` will delete it sooner or later. --[[Joey]]
+
 If, on the other hand, you do git annex add, then edit, then sync, it will actually be committed to the git repository. Fixing that is a lot less trivial than `git prune`.
 
+> This is indeed a problem..
+
 ### What steps will reproduce the problem?
 
     anthony@Watt:/tmp/test$ du -sh .git/objects/
@@ -29,3 +37,20 @@ If, on the other hand, you do git annex add, then edit, then sync, it will actua
 ### What version of git-annex are you using? On what operating system?
 
 5.20141125 on Debian testing/unstable
+
+> Analysis: This only happens when a file is added and then unlocked
+> without first being committed.
+> 
+> In this situation, the file has a typechange between the index and
+> the working tree. However, by the time the pre-commit hook gets
+> run, git commit has already staged the unlocked file content into the
+> index. So, there is nolonger a typechange between the index and the work
+> tree. And, since the file is new, there is no typechange between the
+> index and last commit either. The latter is what the pre-commit hook
+> looks for.
+> 
+> Conclusion: The pre-commit hook cannot possibly detect this situation.
+> Instead, it seems the only way to block the problem is to prevent
+> unlocking a file that does not have any git history.
+> 
+> And I've [[done]] that now. --[[Joey]]