diff --git a/Annex/AutoMerge.hs b/Annex/AutoMerge.hs --- a/Annex/AutoMerge.hs +++ b/Annex/AutoMerge.hs @@ -110,11 +110,11 @@ makelink keyUs -- Our side is annexed file, other side is not. (Just keyUs, Nothing) -> resolveby $ do - graftin them file + graftin them file LsFiles.valThem LsFiles.valThem makelink keyUs -- Our side is not annexed file, other side is. (Nothing, Just keyThem) -> resolveby $ do - graftin us file + graftin us file LsFiles.valUs LsFiles.valUs makelink keyThem -- Neither side is annexed file; cannot resolve. (Nothing, Nothing) -> return Nothing @@ -131,17 +131,41 @@ makelink key = do let dest = variantFile file key l <- inRepo $ gitAnnexLink dest key - ifM isDirect - ( do - d <- fromRepo gitAnnexMergeDir - replaceFile (d dest) $ makeAnnexLink l - , replaceFile dest $ makeAnnexLink l - ) + replacewithlink dest l stageSymlink dest =<< hashSymlink l - {- stage a graft of a directory or file from a branch -} - graftin b item = Annex.Queue.addUpdateIndex - =<< fromRepo (UpdateIndex.lsSubTree b item) + replacewithlink dest link = ifM isDirect + ( do + d <- fromRepo gitAnnexMergeDir + replaceFile (d dest) $ makeGitLink link + , replaceFile dest $ makeGitLink link + ) + + {- Stage a graft of a directory or file from a branch. + - + - When there is a conflicted merge where one side is a directory + - or file, and the other side is a symlink, git merge always + - updates the work tree to contain the non-symlink. So, the + - directory or file will already be in the work tree correctly, + - and they just need to be staged into place. Do so by copying the + - index. (Note that this is also better than calling git-add + - because on a crippled filesystem, it preserves any symlink + - bits.) + - + - It's also possible for the branch to have a symlink in it, + - which is not a git-annex symlink. In this special case, + - git merge does not update the work tree to contain the symlink + - from the branch, so we have to do so manually. + -} + graftin b item select select' = do + Annex.Queue.addUpdateIndex + =<< fromRepo (UpdateIndex.lsSubTree b item) + when (select (LsFiles.unmergedBlobType u) == Just SymlinkBlob) $ + case select' (LsFiles.unmergedSha u) of + Nothing -> noop + Just sha -> do + link <- catLink True sha + replacewithlink item link resolveby a = do {- Remove conflicted file from index so merge can be resolved. -} diff --git a/Annex/CatFile.hs b/Annex/CatFile.hs --- a/Annex/CatFile.hs +++ b/Annex/CatFile.hs @@ -15,6 +15,7 @@ catKey, catKeyFile, catKeyFileHEAD, + catLink, ) where import qualified Data.ByteString.Lazy as L @@ -77,21 +78,25 @@ catKey :: Ref -> FileMode -> Annex (Maybe Key) catKey = catKey' True -catKey' :: Bool -> Ref -> FileMode -> Annex (Maybe Key) -catKey' modeguaranteed ref mode +catKey' :: Bool -> Sha -> FileMode -> Annex (Maybe Key) +catKey' modeguaranteed sha mode | isSymLink mode = do - l <- fromInternalGitPath . decodeBS <$> get + l <- catLink modeguaranteed sha return $ if isLinkToAnnex l then fileKey $ takeFileName l else Nothing | otherwise = return Nothing + +{- Gets a symlink target. -} +catLink :: Bool -> Sha -> Annex String +catLink modeguaranteed sha = fromInternalGitPath . decodeBS <$> get where -- If the mode is not guaranteed to be correct, avoid -- buffering the whole file content, which might be large. -- 8192 is enough if it really is a symlink. get - | modeguaranteed = catObject ref - | otherwise = L.take 8192 <$> catObject ref + | modeguaranteed = catObject sha + | otherwise = L.take 8192 <$> catObject sha {- Looks up the key corresponding to the Ref using the running cat-file. - diff --git a/Annex/Direct.hs b/Annex/Direct.hs --- a/Annex/Direct.hs +++ b/Annex/Direct.hs @@ -5,6 +5,8 @@ - Licensed under the GNU GPL version 3 or higher. -} +{-# LANGUAGE CPP #-} + module Annex.Direct where import Common.Annex @@ -36,6 +38,9 @@ import Annex.VariantFile import Git.Index import Annex.Index +#ifdef mingw32_HOST_OS +import Utility.WinLock +#endif {- Uses git ls-files to find files that need to be committed, and stages - them into the index. Returns True if some changes were staged. -} @@ -150,13 +155,16 @@ - directory, and the merge is staged into a copy of the index. - Then the work tree is updated to reflect the merge, and - finally, the merge is committed and the real index updated. + - + - A lock file is used to avoid races with any other caller of mergeDirect. + - + - To avoid other git processes from making change to the index while our + - merge is in progress, the index lock file is used as the temp index + - file. This is the same as what git does when updating the index + - normally. -} mergeDirect :: Maybe Git.Ref -> Maybe Git.Ref -> Git.Branch -> Annex Bool -> Git.Branch.CommitMode -> Annex Bool -mergeDirect startbranch oldref branch resolvemerge commitmode = do - -- Use the index lock file as the temp index file. - -- This is actually what git does when updating the index, - -- and so it will prevent other git processes from making - -- any changes to the index while our merge is in progress. +mergeDirect startbranch oldref branch resolvemerge commitmode = lockMerge $ do reali <- fromRepo indexFile tmpi <- fromRepo indexFileLock liftIO $ copyFile reali tmpi @@ -174,8 +182,28 @@ else resolvemerge mergeDirectCleanup d (fromMaybe Git.Sha.emptyTree oldref) mergeDirectCommit merged startbranch branch commitmode + liftIO $ rename tmpi reali + return r + +lockMerge :: Annex a -> Annex a +lockMerge a = do + lockfile <- fromRepo gitAnnexMergeLock + createAnnexDirectory $ takeDirectory lockfile + mode <- annexFileMode + bracketIO (lock lockfile mode) unlock (const a) + where +#ifndef mingw32_HOST_OS + lock lockfile mode = do + l <- noUmask mode $ createFile lockfile mode + waitToSetLock l (WriteLock, AbsoluteSeek, 0, 0) + return l + unlock = closeFd +#else + lock lockfile _mode = waitToLock $ lockExclusive lockfile + unlock = dropLock +#endif {- Stage a merge into the index, avoiding changing HEAD or the current - branch. -} diff --git a/Annex/Link.hs b/Annex/Link.hs --- a/Annex/Link.hs +++ b/Annex/Link.hs @@ -68,6 +68,9 @@ then "" else s +makeAnnexLink :: LinkTarget -> FilePath -> Annex () +makeAnnexLink = makeGitLink + {- Creates a link on disk. - - On a filesystem that does not support symlinks, writes the link target @@ -75,8 +78,8 @@ - it's staged as such, so use addAnnexLink when adding a new file or - modified link to git. -} -makeAnnexLink :: LinkTarget -> FilePath -> Annex () -makeAnnexLink linktarget file = ifM (coreSymlinks <$> Annex.getGitConfig) +makeGitLink :: LinkTarget -> FilePath -> Annex () +makeGitLink linktarget file = ifM (coreSymlinks <$> Annex.getGitConfig) ( liftIO $ do void $ tryIO $ removeFile file createSymbolicLink linktarget file diff --git a/Assistant/Threads/Merger.hs b/Assistant/Threads/Merger.hs --- a/Assistant/Threads/Merger.hs +++ b/Assistant/Threads/Merger.hs @@ -78,8 +78,7 @@ changedbranch = fileToBranch file mergecurrent (Just current) - | equivBranches changedbranch current = do - void $ liftAnnex $ autoMergeFrom changedbranch (Just current) Git.Branch.AutomaticCommit + | equivBranches changedbranch current = whenM (liftAnnex $ inRepo $ Git.Branch.changed current changedbranch) $ do debug [ "merging", Git.fromRef changedbranch diff --git a/Build/DistributionUpdate.hs b/Build/DistributionUpdate.hs --- a/Build/DistributionUpdate.hs +++ b/Build/DistributionUpdate.hs @@ -45,7 +45,7 @@ ( autobuild ("android/" ++ v ++ "/git-annex.apk") , "git-annex/android/current/" ++ v ++ "/git-annex.apk" ) - autobuld f = "https://downloads.kitenet.net/git-annex/autobuild/" ++ f + autobuild f = "https://downloads.kitenet.net/git-annex/autobuild/" ++ f main :: IO () main = do diff --git a/CHANGELOG b/CHANGELOG --- a/CHANGELOG +++ b/CHANGELOG @@ -1,3 +1,17 @@ +git-annex (5.20140709) unstable; urgency=medium + + * Fix race in direct mode merge code that could cause all files in the + repository to be removed. It should be able to recover repositories + experiencing this bug without data loss. See: + http://git-annex.branchable.com/bugs/bad_merge_commit_deleting_all_files/ + * Fix git version that supported --no-gpg-sign. + * Fix bug in automatic merge conflict resolution, when one side is an + annexed symlink, and the other side is a non-annexed symlink. + * Really fix bug that caused the assistant to make many unncessary + empty merge commits. + + -- Joey Hess Wed, 09 Jul 2014 15:28:03 -0400 + git-annex (5.20140707) unstable; urgency=medium * assistant: Fix bug, introduced in last release, that caused the assistant diff --git a/Git/Branch.hs b/Git/Branch.hs --- a/Git/Branch.hs +++ b/Git/Branch.hs @@ -113,7 +113,7 @@ applyCommitMode :: CommitMode -> [CommandParam] -> [CommandParam] applyCommitMode commitmode ps - | commitmode == AutomaticCommit && not (Git.BuildVersion.older "1.8.5") = + | commitmode == AutomaticCommit && not (Git.BuildVersion.older "2.0.0") = Param "--no-gpg-sign" : ps | otherwise = ps diff --git a/Locations.hs b/Locations.hs --- a/Locations.hs +++ b/Locations.hs @@ -42,6 +42,7 @@ gitAnnexJournalDir, gitAnnexJournalLock, gitAnnexPreCommitLock, + gitAnnexMergeLock, gitAnnexIndex, gitAnnexIndexStatus, gitAnnexViewIndex, @@ -261,6 +262,10 @@ {- Lock file for the pre-commit hook. -} gitAnnexPreCommitLock :: Git.Repo -> FilePath gitAnnexPreCommitLock r = gitAnnexDir r "precommit.lck" + +{- Lock file for direct mode merge. -} +gitAnnexMergeLock :: Git.Repo -> FilePath +gitAnnexMergeLock r = gitAnnexDir r "merge.lck" {- .git/annex/index is used to stage changes to the git-annex branch -} gitAnnexIndex :: Git.Repo -> FilePath diff --git a/debian/changelog b/debian/changelog --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,17 @@ +git-annex (5.20140709) unstable; urgency=medium + + * Fix race in direct mode merge code that could cause all files in the + repository to be removed. It should be able to recover repositories + experiencing this bug without data loss. See: + http://git-annex.branchable.com/bugs/bad_merge_commit_deleting_all_files/ + * Fix git version that supported --no-gpg-sign. + * Fix bug in automatic merge conflict resolution, when one side is an + annexed symlink, and the other side is a non-annexed symlink. + * Really fix bug that caused the assistant to make many unncessary + empty merge commits. + + -- Joey Hess Wed, 09 Jul 2014 15:28:03 -0400 + git-annex (5.20140707) unstable; urgency=medium * assistant: Fix bug, introduced in last release, that caused the assistant diff --git a/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files.mdwn b/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files.mdwn new file mode 100644 --- /dev/null +++ b/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files.mdwn @@ -0,0 +1,62 @@ +### Please describe the problem. + +The assistant/webapp doesn't drop files from the local (source) repository after transferring it to the 2 backup repositories (numcopies 2), but they are listed with: + + git annex find --want-drop + +### What steps will reproduce the problem? + +#### mintcream #### + + git init annex + cd ~/annex + git commit -m "create" --allow-empty + git annex init mintcream + git annex numcopies 2 + git annex group here source + git config annex.autocommit false + git annex webapp + +#### liquorice #### + + git init annex + cd ~/annex + git annex init liquorice + git annex group here backup + +#### candyfloss #### + + git init annex + cd ~/annex + git annex init candyfloss + git annex group here backup + +#### mintcream #### + + (add both backup repositories in webapp as "remote repositories") + (copy files into ~/annex directory) + git annex add + git commit -m "add some files" + (use "sync now" to prod assistant into noticing the commit) + +### What was I expecting to happen? ### + +The assistant to transfer the files to liquorice and candyfloss, then for the assistant to drop the files from mintcream. + +### What actually happened? ### + +The assistant transfers the files to liquorice and candyfloss. No files are dropped from mintcream. + +### What version of git-annex are you using? On what operating system? + +git-annex version: 5.20140707-g923b436 + +Arch Linux (git-annex-bin from AUR) + +### Please provide any additional information below. + +I wish to retain control of the commits on "master" (annex.autocommit false) but want the assistant to handle moving/dropping the files as required in the background. + + git annex drop --auto + +works as expected. diff --git a/doc/bugs/Assistant_merge_loop.mdwn b/doc/bugs/Assistant_merge_loop.mdwn --- a/doc/bugs/Assistant_merge_loop.mdwn +++ b/doc/bugs/Assistant_merge_loop.mdwn @@ -15,4 +15,5 @@ supported repository version: 5 upgrade supported from repository versions: 0 1 2 4 -> [[fixed|done]] --[[Joey]] +> [[fixed|done]]. Note that 5.20140708 contained an incomplete fix for this +> bug. --[[Joey]] diff --git a/doc/bugs/Merge_involving_symlink_yields_unexpected_results.mdwn b/doc/bugs/Merge_involving_symlink_yields_unexpected_results.mdwn --- a/doc/bugs/Merge_involving_symlink_yields_unexpected_results.mdwn +++ b/doc/bugs/Merge_involving_symlink_yields_unexpected_results.mdwn @@ -45,3 +45,7 @@ Linux 3.15.3 git-annex 5.20140613 + +[[!tag confirmed]] + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X.mdwn b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X.mdwn new file mode 100644 --- /dev/null +++ b/doc/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X.mdwn @@ -0,0 +1,22 @@ +### Please describe the problem. + +On indirect repos on OS X, when a symlink is moved asisstant does not pick it up it. Even though assistant syncs after delete/move changes are not committed. git annex status returns ?? for the moved files. when I run git annex add on the files it says it added them but instead they still show up as ??. the only way to solve the problem is to manually restart the daemon which commits them. + +### What steps will reproduce the problem? + +Moving an annex file. + + +### What version of git-annex are you using? On what operating system? + +5.20140703 g3cfcd54 + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] diff --git a/doc/bugs/__171__transferkey__187___fails_for_bare_remotes.mdwn b/doc/bugs/__171__transferkey__187___fails_for_bare_remotes.mdwn new file mode 100644 --- /dev/null +++ b/doc/bugs/__171__transferkey__187___fails_for_bare_remotes.mdwn @@ -0,0 +1,19 @@ +### Please describe the problem. + +I wanted to inspect the state of an object present in a bare remote +without touching the working copy. So I issued «transferkey $KEY --from +bare-remote»; however, even for keys that are definitely present on +the remote, this would fail with «requested key is not present». + +The same method, when using a non-bare repo in «--from», would succeed +under otherwise identical conditions. + +### What steps will reproduce the problem? + +Cf. above. + +### What version of git-annex are you using? On what operating system? + +git-annex 5.20140708 + +Linux 3.15.4 diff --git a/doc/bugs/bad_merge_commit_deleting_all_files.mdwn b/doc/bugs/bad_merge_commit_deleting_all_files.mdwn new file mode 100644 --- /dev/null +++ b/doc/bugs/bad_merge_commit_deleting_all_files.mdwn @@ -0,0 +1,75 @@ +In our family repository, we had an event where git-annex committed a bad +merge commit. This had the effect of seeming to delete all the files +in the repository. However, it is completely recoverable with no file loss. + +Other users have reported apparently the same problem. +--[[Joey]] + +> This appears to be a race, and I have put in a fix for that. +> It will be released in git-annex 5.20140709. +> +> It's a little bit difficult to say for sure that the bug is fixed, since +> I don't have a good way to reproduce it. However, everything I am seeing +> is consistent with my analysis, at least as far as the people who +> reported this happening with versions 5.20140613-5.20140707. +> Calling this [[done]]. --[[Joey]] + +## recovery + +Look through the git log for the bad commit. It will be the one +that deletes a lot of files. Since the bad commit is a merge commit, +you need to include the -c switch: + + git log -c --stat + +Once the bad commit sha is found, revert it. Since it's a merge commit, +you will need to pass -m 1 to git revert. If the repository you're working +is uses direct mode, you will first need to switch it to indirect mode. + + git annex indirect + git revert -m 1 a36077cf1234eeb755fec8f699d3cbaaee817bac + +(It's possible, but I think unlikely that this will pick the wrong +branch of the merge to revert. If it did, "git reset --hard HEAD@{1}" and +redo, passing `-m 2` instead.) + +Once the revert is done, all your files should be back. You can switch +the repository back to direct mode if desired (`git annex direct`) +and can `git annex sync` to push the fix out to all other clones. +Everywhere the fix lands should restore the deleted files. + +Note that it's possible that some repositories may have pruned the deleted +files as unused. This is most likely to happen in the repository that made +the bad merge commit in the first place. + +[[!tag confirmed urgent]] + +## analysis + +In the one case I have of this happening, the commit was made by the +git-annex assistant, in direct mode. It was git-annex version 5.20140613. +This version had a bug that caused it to do unncessary merge commits. +That bug has been fixed in 5.20140707. +That is apparently related, in that it caused the assistant to do much more +work than normal. + +But, I don't think that bug is fully responsible for the +problem. I think a few users have run into this bug before, although I have +never succeeded in getting a full problem description from anyone who might +have. I think that the unncessary commit bug made it more likely to happen. +(This suggests a race may be involved.) + +The bad merge commit looked like this: + +
+commit a36077cf1234eeb755fec8f699d3cbaaee817bac
+Merge: 52ecff2 9d8bfd4
+Author: xxx
+Date:   Mon Jul 7 19:58:18 2014 -0400
+
+    merge refs/heads/synced/master
+
+ +Both parent trees were good and contained all files. In fact, the 2 +parent trees contained the same set of files. But the merge commit +"resolved" the merge by deleting all the files. diff --git a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain.mdwn b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain.mdwn --- a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain.mdwn +++ b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain.mdwn @@ -17,3 +17,5 @@ # End of transcript or log. """]] + +[[!tag moreinfo]] diff --git a/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state.mdwn b/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state.mdwn new file mode 100644 --- /dev/null +++ b/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state.mdwn @@ -0,0 +1,58 @@ +### Please describe the problem. + +Running `git annex direct` in a repository may results with the following error message: + + git-annex: /home/mildred/Music/.git/annex/objects/2K/49/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.map898.tmp: rename: permission denied (Permission denied) +failed + git-annex: direct: 1 failed + + +The major problem is that git-annex doesn't roll back the changes it did for the files it could successfully put in direct mode. Running git status show many files with typechange. The solution was to run `git add` on those files (although the hashing backend changed, so a commit must be created) + +### What steps will reproduce the problem? + +Don't know yet why the rename failed, but the direct mode should be rolled back if there is a problem. Restarting `git-annex direct` didn't result in an error. + +### What version of git-annex are you using? On what operating system? + +git-annex 5.20140405-g8729abc +arch-linux Linux moiraine 3.15.3-1-ARCH #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014 x86_64 GNU/Linux + +### Please provide any additional information below. + +[[!format sh """ + +$ git annex direct +commit +(Recording state in git...) +On branch master +nothing to commit, working directory clean +ok +direct .gitrefs/heads/annex/direct/master ok +direct .gitrefs/heads/git-annex ok +direct .gitrefs/heads/master ok +direct .gitrefs/heads/synced/master ok +direct .gitrefs/remotes/ashley/git-annex ok +direct .gitrefs/remotes/ashley/master ok +direct .gitrefs/remotes/ashley/synced/git-annex ok +direct .gitrefs/remotes/ashley/synced/master ok +direct .gitrefs/remotes/kylae/git-annex ok +direct .gitrefs/remotes/kylae/master ok +direct .gitrefs/remotes/kylae/synced/git-annex ok +direct ... ok +direct ... ok +direct ... ok + /home/mildred/Music/.git/annex/objects/2K/49/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.map897.tmp: rename: permission denied (Permission denied) + + leaving this file as-is; correct this problem and run git annex fsck on it +direct ... ok +direct ... ok +direct ... ok +direct ... ok +direct ... ok + +git-annex: /home/mildred/Music/.git/annex/objects/2K/49/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.map898.tmp: rename: permission denied (Permission denied) +failed +git-annex: direct: 1 failed + +"""]] diff --git a/doc/bugs/direct_mode_should_refuse_to_merge_with_illegal_filenames.mdwn b/doc/bugs/direct_mode_should_refuse_to_merge_with_illegal_filenames.mdwn --- a/doc/bugs/direct_mode_should_refuse_to_merge_with_illegal_filenames.mdwn +++ b/doc/bugs/direct_mode_should_refuse_to_merge_with_illegal_filenames.mdwn @@ -32,4 +32,7 @@ ---- -Alternatively, git-annex could learn/probe the full set of characters not allowed in filenames, and examine merges before performing them, and refuse to do anything if the merge added an illegal filename. +Alternatively, git-annex could learn/probe the full set of characters not allowed in filenames, and examine merges before performing them, and refuse to do anything if the merge added an illegal filename.a + +[[!tag confirmed]] + diff --git a/doc/bugs/git-annex.app_doesn__39__t_seem_to_use_the_bundled_git.mdwn b/doc/bugs/git-annex.app_doesn__39__t_seem_to_use_the_bundled_git.mdwn new file mode 100644 --- /dev/null +++ b/doc/bugs/git-annex.app_doesn__39__t_seem_to_use_the_bundled_git.mdwn @@ -0,0 +1,50 @@ +### Please describe the problem. + +When trying to create a repository—i.e., running it for the first time—I get this error message: + +> user error (git ["--git-dir=(path)/.git","--work-tree=(path)","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"] exited 128) + +It _seems_ that it's because the bundled `git` executable isn't used, and instead `/usr/bin/git` is; and it's too old to support the `--no-gpg-sign` flag. + + +### What steps will reproduce the problem? + +Run `git-annex.app` for the first time and give it a path. + + +### What version of git-annex are you using? On what operating system? + + $ /Applications/Git-Annex.app/Contents/MacOS/git-annex version + git-annex version: 5.20140707-gf0c48e8 + build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash + key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL + remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external + + +### Please provide any additional information below. + +`…/.git/annex/daemon.log` doesn't exist + + $ tree -a + . + ├── .DS_Store + └── .git + ├── HEAD + ├── annex + │   ├── index + │   ├── misctmp + │   ├── sentinal + │   └── sentinal.cache + ├── config + ├── hooks + │   └── pre-commit + ├── objects + │   ├── 4b + │   │   └── 825dc642cb6eb9a060e54bf8d69288fbee4904 + │   ├── info + │   └── pack + └── refs + ├── heads + └── tags + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/gpg_does_not_ask_for_password_inside_tmux.mdwn b/doc/bugs/gpg_does_not_ask_for_password_inside_tmux.mdwn new file mode 100644 --- /dev/null +++ b/doc/bugs/gpg_does_not_ask_for_password_inside_tmux.mdwn @@ -0,0 +1,21 @@ +### Please describe the problem. + +When commands that need gpg like `git annex copy` are run inside tmux, the GPG prompt does not show up and the user cannot give their password. + +Running the same command outside tmux causes GPG to properly show its prompt + +### What steps will reproduce the problem? + + $ tmux + TMUX$ GIT_ANNEX_ROOT/runshell + TMUX$ git annex copy --not -in remote --to remote + +git-annex will show the name of the first filename but will get stuck soon after that, waiting for GPG. + +### What version of git-annex are you using? On what operating system? + +git-annex 5.20140708-g8c9cc55c from the precompiled binaries, run inside tmux 1.6. + +`tmux.conf` contains `set-option -g default-command $SHELL` (this means that a normal shell is spawned, not a login shell) + +Ubuntu 12.04.4 diff --git a/doc/builds.mdwn b/doc/builds.mdwn --- a/doc/builds.mdwn +++ b/doc/builds.mdwn @@ -1,6 +1,31 @@ [[!meta title="git-annex autobuild overview"]] +[[!sidebar content=""" +# last uploaded build-versions +

Linux i386

+ +

Linux amd64

+ +

Linux armel

+ +

Android

+ +

OSX Mavericks

+ +

Windows

+ +"""]] + +# build logs + +

Linux i386

Linux amd64

@@ -17,4 +42,3 @@

Windows

here - diff --git a/doc/design/roadmap.mdwn b/doc/design/roadmap.mdwn --- a/doc/design/roadmap.mdwn +++ b/doc/design/roadmap.mdwn @@ -13,6 +13,6 @@ * Month 7 user-driven features and polishing * Month 8 [[!traillink git-remote-daemon]] * Month 9 Brazil!, [[!traillink assistant/sshpassword]] -* **Month 10 polish [[assistant/Windows]] port** -* Month 11 [[!traillink assistant/chunks]], [[!traillink assistant/deltas]], [[!traillink assistant/gpgkeys]] (pick 2?) +* Month 10 polish [[assistant/Windows]] port +* **Month 11 [[!traillink assistant/chunks]], [[!traillink assistant/deltas]], [[!traillink assistant/gpgkeys]] (pick 2?)** * Month 12 [[!traillink assistant/telehash]] diff --git a/doc/devblog/day_192__release_day.mdwn b/doc/devblog/day_192__release_day.mdwn new file mode 100644 --- /dev/null +++ b/doc/devblog/day_192__release_day.mdwn @@ -0,0 +1,4 @@ +Got the release out. Had to fix various autobuilder issues. The arm autobuilder +is unfortunatly not working currently. + +Updated git-annex to build with a new version of the bloomfilter library. diff --git a/doc/forum/Best_approach_for_central_sharing_and_multiple_users.mdwn b/doc/forum/Best_approach_for_central_sharing_and_multiple_users.mdwn new file mode 100644 --- /dev/null +++ b/doc/forum/Best_approach_for_central_sharing_and_multiple_users.mdwn @@ -0,0 +1,8 @@ +Just a quick question: Can anyone recomment me a good to handle a centralized repository which is used by different users? + +Requirements: must work in direct mode on both sides, server is Linux, clients are Windows and operated by 2 different users. + +- Should the repository create bare or not? +- Must the repository created on the server or can it also be "pushed" from one client to the server (via SSH on the server)? +- Is there a better way for data transfer than SSH (WebDAV as in SVN)? I am still struggling with an elegant way to handle public keys in windows +- What is the best way to not only keep meta data in sync but also the data each of the users has checked out? diff --git a/doc/forum/Ssh_remote_on_NAS.mdwn b/doc/forum/Ssh_remote_on_NAS.mdwn new file mode 100644 --- /dev/null +++ b/doc/forum/Ssh_remote_on_NAS.mdwn @@ -0,0 +1,34 @@ +Hello, + +I finally have git annex working on my NAS (QNAP TS-119P II) thanks to the stand-alone arm pre-build package. + +I've just extracted all the files on my NAS and I've linked all the exec files from the git-annex.linux folder to links placed in a path folder, so that I can run git annex everywhere on the NAS. + + [~] # git annex version + git-annex version: 5.20140528-g92a0591 + build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash + key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL + remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external + +Now I'm trying to set it up as an SSH remote of my laptop repository, but I get this error: + + git clone ssh://admin@nas:/share/HDA_DATA/myDir ./ + Cloning into '.'... + admin@nas's password: + sh: git-upload-pack: command not found + fatal: Could not read from remote repository. + + Please make sure you have the correct access rights + and the repository exists. + +I've checked that git-upload-pack is available both on my laptop and on the NAS and the "myDir" folder is supposed to be readable for the admin user on the NAS, even if the user I use on the laptop and on the NAS for git annex is different from the one I use to login. In fact, if I try to scp files from the annex folder then I don't get any permissions error. + + scp admin@192.168.132.66:/share/HDA_DATA/myDir/* ./ + admin@192.168.132.66's password: + doctest 100% 5 0.0KB/s 0.0KB/s 00:00 + doctest2 100% 51 0.1KB/s 0.1KB/s 00:01 + +Is there something else I should look at, in order to fix it and make it work? + +Thanks, +Fabio diff --git a/doc/forum/__171__Locking__187___files_until_synced.mdwn b/doc/forum/__171__Locking__187___files_until_synced.mdwn new file mode 100644 --- /dev/null +++ b/doc/forum/__171__Locking__187___files_until_synced.mdwn @@ -0,0 +1,7 @@ +I’m currently trying to set up a sync which involves an SQLite3 database file that should always be in the same state on all systems at all times (since there is no readily available way of merging the data). Basically, I’m looking for a practical way that gives me some help in making sure the files never drift apart between my remotes. Since I’m forgetful and might forget syncing the repo before going home from the office, I was wondering whether there might be a good way to assist me in this. Has anyone had some good ideas in this direction, or is there a canonical solution? + +It occurred to me one way would be to instate a hook somewhere that links the database to /dev/null in all other remotes (so the software will fail to work if I start it without having synced), but it seems tricky. I guess would have to involve per-remote branches, which will be hard to do, since I need to use direct mode. + +A less complex method might be forcing a sync before shutting down the system resp. when booting up. + +Maybe other folks have had ideas for a practical, yet robust solution. diff --git a/doc/forum/ghost_semitrusted_repositories.mdwn b/doc/forum/ghost_semitrusted_repositories.mdwn new file mode 100644 --- /dev/null +++ b/doc/forum/ghost_semitrusted_repositories.mdwn @@ -0,0 +1,28 @@ +I had one repo on HDD and another in an USB drive. After mount point changed, I went to the HDD repo folder and tried to use git remote-set url to point it to the new location, however I think I ended in a weird state. git-annex info shows this: + + git-annex info + repository mode: indirect + trusted repositories: 0 + semitrusted repositories: 5 + 00000000-0000-0000-0000-000000000001 -- web + 26c0c4ba-6489-4416-a054-670d373f09bd -- juan@invasor.local:/Volumes/sapo_hfs/live/papers + 61158820-db14-45b9-b9f9-8619d956388e -- [usb_papers] + d4456c86-fa2b-43a7-a132-027915390cf6 -- usb_papers + fed56814-08c6-11e3-bf3c-af5da9f7f388 -- sapo [here] + untrusted repositories: 0 + transfers in progress: none + available local disk space: 255.46 gigabytes (+1 megabyte reserved) + local annex keys: 1252 + local annex size: 2.55 gigabytes + annexed files in working tree: 1297 + size of annexed files in working tree: 2.7 gigabytes + bloom filter size: 16 mebibytes (0.3% full) + backend usage: + SHA256E: 2549 + +usb_papers was the original usb repo, and now a new one [usb_papers] shows. webapp shows only sapo[here] and [usb_papers], the other 2 repos are unknown. I was digging around but couldn't find a way to remove them. +Seems that the webapp managed to use the new URL, but said something about "fixing repo". +Any suggestions? +Thanks in advance. +Best regards, + Juan diff --git a/doc/forum/update_via_cabal_fails.mdwn b/doc/forum/update_via_cabal_fails.mdwn new file mode 100644 --- /dev/null +++ b/doc/forum/update_via_cabal_fails.mdwn @@ -0,0 +1,35 @@ +I tried to update git-annex via cabal. It fails due to lens not installing: + + juh@sokrates:~$ cabal update + Downloading the latest package list from hackage.haskell.org + juh@sokrates:~$ cabal install git-annex + Resolving dependencies... + In order, the following will be installed: + lens-4.2 (new version) + DAV-0.6.2 (reinstall) changes: http-client-0.3.1.1 -> 0.3.3.1, + http-client-tls-0.2.1.1 added, http-types-0.8.4 -> 0.8.5, lens-4.1.2 -> 4.2, + network-2.4.1.2 added, optparse-applicative-0.7.0.2 added, xml- conduit-1.2.0.1 + -> 1.2.0.2, xml-hamlet-0.4.0.8 added + git-annex-5.20140707 (new package) + Warning: Note that reinstalls are always dangerous. Continuing anyway... + [1 of 1] Compiling Main ( /tmp/lens-4.2-3107/lens-4.2/Setup. lhs, /tmp/lens-4.2-3107/lens-4.2/dist/setup/Main.o ) + Linking /tmp/lens-4.2-3107/lens-4.2/dist/setup/setup ... + Configuring lens-4.2... + Building lens-4.2... + Preprocessing library lens-4.2... + + src/Control/Lens/Internal/Zoom.hs:47:8: + Could not find module `Control.Monad.Trans.Except' + Perhaps you meant + Control.Monad.Trans.Cont (from transformers-0.3.0.0) + Control.Monad.Trans.Error (from transformers-0.3.0.0) + Control.Monad.Trans.List (from transformers-0.3.0.0) + Use -v to see a list of the files searched for. + Failed to install lens-4.2 + cabal: Error: some packages failed to install: + DAV-0.6.2 depends on lens-4.2 which failed to install. + git-annex-5.20140707 depends on lens-4.2 which failed to install. + lens-4.2 failed during the building phase. The exception was: + ExitFailure 1 + +I am not an experienced user of cabal. So any hints to solve the conflicts are appreciated. diff --git a/doc/news/version_5.20140517.mdwn b/doc/news/version_5.20140517.mdwn deleted file mode 100644 --- a/doc/news/version_5.20140517.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -git-annex 5.20140517 released with [[!toggle text="these changes"]] -[[!toggleable text=""" - * webapp: Switched to bootstrap 3. - Thanks, Sören Brunk. - * Standalone builds now check gpg signatures before upgrading. - * Simplified repository description line format. The remote name, - if any, is always in square brackets after the description. - * assistant: Clean up stale tmp files on startup. - * webapp: Better ssh password prompting. - * Depend on git-remote-gcrypt 0.20130908-6. Older versions - fail when the assistant is run with no controlling tty. - * Added ddar special remote. - Thanks, Robie Basak. - * webapp: Fixed drag and drop to reorder the list of remotes. - * group: When no groups are specified to set, lists the current groups - of a repository. - * Add remote.$name.annex-shell configuration. - Thanks, Fraser Tweedale - * Support symlinking git-annex and git-annex-shell - from the Linux standalone bundle into PATH. - Thanks, jlebar."""]] diff --git a/doc/news/version_5.20140709.mdwn b/doc/news/version_5.20140709.mdwn new file mode 100644 --- /dev/null +++ b/doc/news/version_5.20140709.mdwn @@ -0,0 +1,11 @@ +git-annex 5.20140709 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Fix race in direct mode merge code that could cause all files in the + repository to be removed. It should be able to recover repositories + experiencing this bug without data loss. See: + http://git-annex.branchable.com/bugs/bad\_merge\_commit\_deleting\_all\_files/ + * Fix git version that supported --no-gpg-sign. + * Fix bug in automatic merge conflict resolution, when one side is an + annexed symlink, and the other side is a non-annexed symlink. + * Really fix bug that caused the assistant to make many unncessary + empty merge commits."""]] diff --git a/git-annex.cabal b/git-annex.cabal --- a/git-annex.cabal +++ b/git-annex.cabal @@ -1,5 +1,5 @@ Name: git-annex -Version: 5.20140707 +Version: 5.20140709 Cabal-Version: >= 1.8 License: GPL-3 Maintainer: Joey Hess