diff options
-rw-r--r-- | Command/Unlock.hs | 42 | ||||
-rw-r--r-- | debian/changelog | 8 | ||||
-rw-r--r-- | doc/bugs/git_annex_sync_can_commit_files_to_.git__47__objects_instead_of_.git__47__annex.mdwn | 25 |
3 files changed, 57 insertions, 18 deletions
diff --git a/Command/Unlock.hs b/Command/Unlock.hs index bed618104..56c4f1dc0 100644 --- a/Command/Unlock.hs +++ b/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 + ) diff --git a/debian/changelog b/debian/changelog index fcf1d1fa9..876753566 100644 --- a/debian/changelog +++ b/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. diff --git a/doc/bugs/git_annex_sync_can_commit_files_to_.git__47__objects_instead_of_.git__47__annex.mdwn b/doc/bugs/git_annex_sync_can_commit_files_to_.git__47__objects_instead_of_.git__47__annex.mdwn index 9235c002f..76260cb5c 100644 --- a/doc/bugs/git_annex_sync_can_commit_files_to_.git__47__objects_instead_of_.git__47__annex.mdwn +++ b/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]] |