diff options
4 files changed, 47 insertions, 0 deletions
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 000000000..0245a0b16 --- /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. +"""]] 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 000000000..72de2a518 --- /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. :-) +"""]] 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 000000000..a92c9ac9a --- /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. :) +"""]] 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 000000000..1957eb2ac --- /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? +"""]] |