From f62dbd744558f4f209efc45958d50e44fd42800a Mon Sep 17 00:00:00 2001 From: archimedes Date: Wed, 5 Apr 2017 20:01:44 +0000 Subject: [PATCH 1/4] Added a comment --- ...ment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/forum/Split_annex_into_multiple/comment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment diff --git a/doc/forum/Split_annex_into_multiple/comment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment b/doc/forum/Split_annex_into_multiple/comment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment new file mode 100644 index 0000000000..1957eb2ac8 --- /dev/null +++ b/doc/forum/Split_annex_into_multiple/comment_2_eec6bc8c49c08411a4bb2cf7cc1c4697._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="archimedes" + avatar="http://cdn.libravatar.org/avatar/5b2ed40aabedcb1b8c2c0ce69f55a1e1" + subject="comment 2" + date="2017-04-05T20:01:44Z" + content=""" +So actually \"import --reinject-duplicates\" solves the issue of reinject not being recursive. + + +That trick on .git/annex/objects/ is cunning, but the destruction of Global before everything has been finished is discomforting...if only there was a \"--reinject-duplicates --duplicate\" option for import. + +No chance that I can make a recursive copy of .git/annex/objects with hardlinks can I? To then use with reinject-duplicates? +"""]] From c74490e627e6e267a6c2fe8ffc5084c05be2aa41 Mon Sep 17 00:00:00 2001 From: spwhitton Date: Wed, 5 Apr 2017 22:28:11 +0000 Subject: [PATCH 2/4] Added a comment --- ...t_4_0f82673281494b1cb084dce702525a01._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_4_0f82673281494b1cb084dce702525a01._comment diff --git a/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_4_0f82673281494b1cb084dce702525a01._comment b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_4_0f82673281494b1cb084dce702525a01._comment new file mode 100644 index 0000000000..0245a0b166 --- /dev/null +++ b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_4_0f82673281494b1cb084dce702525a01._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="spwhitton" + avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb" + subject="comment 4" + date="2017-04-05T22:28:10Z" + content=""" +git-remote-gcrypt maintainer here. + +As Joey recommends for the meantime, I am successfully using an `rsync://` gcrypt remote plus a separate encrypted git-annex rsync remote to work around these performance issues. + +git-remote-gcrypt relies on rsync to implement the incremental upload, so the README is wrong to suggest that using an `sftp://` remote would work around this issue -- git-remote-gcrypt invokes curl for the sftp transaction, which as far as I know does nothing incremental (that's presumably why rsync exists). I've just updated the README. + +If we wanted the gitception gcrypt remote to be incremental, we would need to implement rsync-like incremental uploads on top of the structure of git commits, such that we could push a git commit that represents the changes to the gcrypt packfiles and manifest since the previous commit. But I don't think this is possible for binary files -- I don't think git can represent the deltas efficiently. + +I've come to think that git-remote-gcrypt's gitception mode is not actually very useful, simply due to the design of git. But perhaps there is an alternative way to represent the manifest and packfiles that would be compatible with incremental git pushes. +"""]] From 3d3a5737464fcdec46515ca598d83cf53799bbac Mon Sep 17 00:00:00 2001 From: woffs Date: Thu, 6 Apr 2017 07:29:14 +0000 Subject: [PATCH 3/4] Added a comment --- ...comment_5_39d905d4577c9b2987bf5e6cdbace7f2._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_5_39d905d4577c9b2987bf5e6cdbace7f2._comment diff --git a/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_5_39d905d4577c9b2987bf5e6cdbace7f2._comment b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_5_39d905d4577c9b2987bf5e6cdbace7f2._comment new file mode 100644 index 0000000000..72de2a5189 --- /dev/null +++ b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_5_39d905d4577c9b2987bf5e6cdbace7f2._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="woffs" + avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6" + subject="comment 5" + date="2017-04-06T07:29:14Z" + content=""" +I remember having tried this (gcrypt rsync:// git remote + rsync encrypted git-annex specialremote) but I was disappointed because git-annex-sync does not pull/push the git remote and I had to do this separately every time. + +Anyway, thank you for caring. :-) +"""]] From 74400e294b8454b94f9f2f93fa3e41c1e7e4d404 Mon Sep 17 00:00:00 2001 From: woffs Date: Thu, 6 Apr 2017 08:28:06 +0000 Subject: [PATCH 4/4] Added a comment --- .../comment_6_a7c02a4dfa74de8ad05bfaaee0b335b8._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_6_a7c02a4dfa74de8ad05bfaaee0b335b8._comment diff --git a/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_6_a7c02a4dfa74de8ad05bfaaee0b335b8._comment b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_6_a7c02a4dfa74de8ad05bfaaee0b335b8._comment new file mode 100644 index 0000000000..a92c9ac9ae --- /dev/null +++ b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest/comment_6_a7c02a4dfa74de8ad05bfaaee0b335b8._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="woffs" + avatar="http://cdn.libravatar.org/avatar/198790d74209efe4896fd4cfc37ec2a6" + subject="comment 6" + date="2017-04-06T08:28:06Z" + content=""" +I was wrong. git-annex-sync DOES pull/push to the gcrypt rsync remote. So seems fine. Thank you. :) +"""]]