diff options
14 files changed, 79 insertions, 21 deletions
diff --git a/Annex/Fixup.hs b/Annex/Fixup.hs index 99b4ea2d5..4d9afea91 100644 --- a/Annex/Fixup.hs +++ b/Annex/Fixup.hs @@ -11,6 +11,7 @@ import Git.Types import Git.Config import Types.GitConfig import qualified Git.Construct as Construct +import qualified Git.BuildVersion import Utility.Path import Utility.SafeCommand import Utility.Directory @@ -36,8 +37,10 @@ fixupRepo r c = do {- Disable git's built-in wildcard expansion, which is not wanted - when using it as plumbing by git-annex. -} disableWildcardExpansion :: Repo -> Repo -disableWildcardExpansion r = r - { gitGlobalOpts = gitGlobalOpts r ++ [Param "--literal-pathspecs"] } +disableWildcardExpansion r + | Git.BuildVersion.older "1.8.1" = r + | otherwise = r + { gitGlobalOpts = gitGlobalOpts r ++ [Param "--literal-pathspecs"] } {- Direct mode repos have core.bare=true, but are not really bare. - Fix up the Repo to be a non-bare repo, and arrange for git commands diff --git a/debian/changelog b/debian/changelog index eea9bab0b..ae501555a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,4 +1,4 @@ -git-annex (5.20150405) UNRELEASED; urgency=medium +git-annex (5.20150406) unstable; urgency=medium * Prevent git-ls-files from double-expanding wildcards when an unexpanded wildcard is passed to a git-annex command like add or find. @@ -10,7 +10,7 @@ git-annex (5.20150405) UNRELEASED; urgency=medium guid has been downloaded before, even when the url has changed. * importfeed: Always store itemid in metadata; before this was only done when annex.genmetadata was set. - * Relax debian package dependencies to git >= 1:1.7.7.6 rather + * Relax debian package dependencies to git >= 1:1.8.1 rather than needing >= 1:2.0. * test: Fix --list-tests * addurl --file: When used with a special remote that claims @@ -32,7 +32,7 @@ git-annex (5.20150405) UNRELEASED; urgency=medium (The option already suppressed git-annex's own built-in progress displays.) - -- Joey Hess <id@joeyh.name> Fri, 27 Mar 2015 16:04:43 -0400 + -- Joey Hess <id@joeyh.name> Mon, 06 Apr 2015 12:48:48 -0400 git-annex (5.20150327) unstable; urgency=medium diff --git a/debian/control b/debian/control index 937444135..6cb4a6327 100644 --- a/debian/control +++ b/debian/control @@ -75,7 +75,7 @@ Build-Depends: lsof [!kfreebsd-i386 !kfreebsd-amd64 !hurd-any], ikiwiki, perlmagick, - git (>= 1:1.7.7.6), + git (>= 1:1.8.1), rsync, wget, curl, @@ -92,7 +92,7 @@ Package: git-annex Architecture: any Section: utils Depends: ${misc:Depends}, ${shlibs:Depends}, - git (>= 1:1.7.7.6), + git (>= 1:1.8.1), rsync, wget, curl, diff --git a/doc/bugs/feature_request:_pubkey-only_encryption_mode.mdwn b/doc/bugs/feature_request:_pubkey-only_encryption_mode.mdwn deleted file mode 100644 index ff2fe7fae..000000000 --- a/doc/bugs/feature_request:_pubkey-only_encryption_mode.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -### Feature request -It is not possible to put encrypted content in place on remotes with just a public GPG key. You always need the private key, even for encryption. I guess this is because how the cipher HMAC is used for replacing file names with their hashes. However, if that requirement (having secret file names) was dropped, I assume a pubkey-only mode could be implemented? - -My specific use case is backup archiving. I have my backups packed in archive files and want to use git-annex to copy the archives to offsite remotes (S3). In that case, I don't care much about hiding file names, but would appreciate the increased security of not having the secret key on the backup server. It would only be needed if I wanted to verify or restore backups. - -> [[closed|done]] per my comment --[[Joey]] diff --git a/doc/tips/downloading_podcasts/comment_25_aedc6a33796bfed2896b49ff70324095._comment b/doc/bugs/importfeed_fails_with_local_file_urls.mdwn index f24efd442..5984458ab 100644 --- a/doc/tips/downloading_podcasts/comment_25_aedc6a33796bfed2896b49ff70324095._comment +++ b/doc/bugs/importfeed_fails_with_local_file_urls.mdwn @@ -1,8 +1,3 @@ -[[!comment format=mdwn - username="mac" - subject="importfeeds with file based rss contents" - date="2015-04-04T20:42:27Z" - content=""" Hi, I've a script which generates .rss files which reference local files with the file:// scheme. I can import the file:// urls with git annex addurl, but it fails with git annex importfeed: @@ -31,5 +26,3 @@ Is it possible to use local files in rss format with items which reference local Cheers, Marco - -"""]] diff --git a/doc/forum/Using_git-annex_to_manage_git_repositories/comment_2_ab24098c2f4519cbbfdcd00ba3e21d2b._comment b/doc/forum/Using_git-annex_to_manage_git_repositories/comment_2_ab24098c2f4519cbbfdcd00ba3e21d2b._comment new file mode 100644 index 000000000..87fe1768b --- /dev/null +++ b/doc/forum/Using_git-annex_to_manage_git_repositories/comment_2_ab24098c2f4519cbbfdcd00ba3e21d2b._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2015-04-06T17:01:32Z" + content=""" +This is not what git-annex was designed to do, so I don't think it's the +right tool for the job. + +I suggest <http://myrepos.branchable.com/> +"""]] diff --git a/doc/forum/two_lines_back_to_remote__63__/comment_2_b1debe6f63e811c79ad97b9e38dd2935._comment b/doc/forum/two_lines_back_to_remote__63__/comment_2_b1debe6f63e811c79ad97b9e38dd2935._comment new file mode 100644 index 000000000..1bd432939 --- /dev/null +++ b/doc/forum/two_lines_back_to_remote__63__/comment_2_b1debe6f63e811c79ad97b9e38dd2935._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2015-04-06T16:59:07Z" + content=""" + +"""]] diff --git a/doc/forum/two_lines_back_to_remote__63__/comment_3_70ee40b99e06c4f64d3e2e4433c8b4ba._comment b/doc/forum/two_lines_back_to_remote__63__/comment_3_70ee40b99e06c4f64d3e2e4433c8b4ba._comment new file mode 100644 index 000000000..7f7389b8b --- /dev/null +++ b/doc/forum/two_lines_back_to_remote__63__/comment_3_70ee40b99e06c4f64d3e2e4433c8b4ba._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2015-04-06T16:59:10Z" + content=""" +The map shows one line for each git remote. So if you have two git remotes +configured that are both pointing at the laptop, that'll be the result. +For example, you might have both "origin" and "laptop" remotes pointing to +it, possibly via two different urls. + +There's nothing bad about this. +"""]] diff --git a/doc/todo/feature_request:_pubkey-only_encryption_mode.mdwn b/doc/todo/feature_request:_pubkey-only_encryption_mode.mdwn new file mode 100644 index 000000000..2bfc629dd --- /dev/null +++ b/doc/todo/feature_request:_pubkey-only_encryption_mode.mdwn @@ -0,0 +1,14 @@ +### Feature request + +It is not possible to put encrypted content in place on remotes with just a +public GPG key. You always need the private key, even for encryption. I +guess this is because how the cipher HMAC is used for replacing file names +with their hashes. However, if that requirement (having secret file names) +was dropped, I assume a pubkey-only mode could be implemented? + +My specific use case is backup archiving. I have my backups packed in +archive files and want to use git-annex to copy the archives to offsite +remotes (S3). In that case, I don't care much about hiding file names, but +would appreciate the increased security of not having the secret key on the +backup server. It would only be needed if I wanted to verify or restore +backups. diff --git a/doc/bugs/feature_request:_pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment index 0e2f5e3ba..0e2f5e3ba 100644 --- a/doc/bugs/feature_request:_pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment +++ b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_1_684d36c06429306be68fd60019564db3._comment diff --git a/doc/bugs/feature_request:_pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment index 88a45312d..88a45312d 100644 --- a/doc/bugs/feature_request:_pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment +++ b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_2_13995d4f1142a393ff977859b86497b4._comment diff --git a/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment new file mode 100644 index 000000000..1278aaab3 --- /dev/null +++ b/doc/todo/feature_request:_pubkey-only_encryption_mode/comment_3_a37d5d27d073020ccf7eadb8e47d378a._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2015-04-06T17:04:34Z" + content=""" +I somehow completely misread what you wanted! Thanks, it makes sense now. + +I anticipate there would be one problem with this mode; `git annex fsck --from remote` +would fail because it would be unable to decrypt the encrypted content +when run on the client that is only able to encrypt to the public key, but +lacks the necessary private key to decrypt. + +(So would `git annex move --to remote; git annex get --from remote`, but +presumably that failure is the point of the mode..) + +It would be fairly easy to add this, I think. There is already support +for configuring the MAC algorithm to use to encrypt filenames. Your mode seems +to just need a "clear" mode that doesn't encrypt filenames at all. + +It does add complication to crypto paths, and potential for user +foot-shooting though. + +I'm going to move this feature request from bugs/ to todo/ +"""]] diff --git a/git-annex.cabal b/git-annex.cabal index dcf46a3c2..14d368709 100644 --- a/git-annex.cabal +++ b/git-annex.cabal @@ -1,5 +1,5 @@ Name: git-annex -Version: 5.20150327 +Version: 5.20150406 Cabal-Version: >= 1.8 License: GPL-3 Maintainer: Joey Hess <id@joeyh.name> diff --git a/standalone/windows/build.sh b/standalone/windows/build.sh index 09161c569..b1185c3da 100755 --- a/standalone/windows/build.sh +++ b/standalone/windows/build.sh @@ -44,6 +44,7 @@ cabal install --only-dependencies || true # Detect when the last build was an incremental build and failed, # and try a full build. Done this way because this shell seems a bit # broken. +cabal clean if [ -e last-incremental-failed ]; then cabal clean || true # windows breakage.. |