From c4839e03f70c55ddb353f26ea54c0e4c3b18efc0 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" Date: Sun, 24 Aug 2014 02:55:33 +0000 Subject: [PATCH 01/19] --- .../git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn | 1 + 1 file changed, 1 insertion(+) create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn new file mode 100644 index 0000000000..e091460dcb --- /dev/null +++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn @@ -0,0 +1 @@ +So, you provide ARM build. But you probably don't know that my NAS box runs OABI. No, you don't know, you can't know, and you shouldn't know. The only thing worth knowing is that writing great software in obscure and esoteric languages drastically limits its usage, impact, and collaboration around it. So, any idea of writing git-annex implementation in a sane, interpreted, "just works" language, e.g. Python? Thanks. From 1f25a79e0849b139c1d429ce7062875ab7dfc7d0 Mon Sep 17 00:00:00 2001 From: "http://svario.it/gioele" Date: Sun, 24 Aug 2014 10:41:58 +0000 Subject: [PATCH 02/19] Added a comment --- ...ent_1_29eda7ec1519f339d5b3601559fe0bb0._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment new file mode 100644 index 0000000000..1cf6c84d6f --- /dev/null +++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://svario.it/gioele" + nickname="gioele" + subject="comment 1" + date="2014-08-24T10:41:58Z" + content=""" +> git-annex implementation in a sane, interpreted, \"just works\" language, e.g. Python? Thanks. + +Good luck finding anything that works on OARM. Python itself does not support OABI: + +> This issue remains as \"won't fix\". ARM is supported; just OABI is not, and never will be. If anybody needs that, they will have to maintain their own fork of Python. + +(from ) +"""]] From 030e9aa7f02dceab2dfded928d936ca77f803f72 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" Date: Sun, 24 Aug 2014 11:04:21 +0000 Subject: [PATCH 03/19] Added a comment --- ...omment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment new file mode 100644 index 0000000000..32318b404a --- /dev/null +++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" + nickname="Paul" + subject="comment 2" + date="2014-08-24T11:04:21Z" + content=""" +Python on this system \"just works\". That's because Python is a project with a real community, so if one pundit said \"not supported\", dozen of people shrugged and typed \"make\", then packed up result for thousands to use. + +But don't get carried away by OABI, that was just one random example how deployment of git-annex is problematic. There're bigger issues like community involvement, being able to investigate and resolve issues, submit patches, bring new working ideas, make git-annex development and lifecycle sustainable, in the end - as vividly cared by the author. + +"""]] From a9f886f69a203b615cad5db392a20b9ae316860e Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" Date: Sun, 24 Aug 2014 11:53:11 +0000 Subject: [PATCH 04/19] Added a comment --- ..._765334858ef1eedff2c5d89ed42aa7f6._comment | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment diff --git a/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment b/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment new file mode 100644 index 0000000000..66615dac78 --- /dev/null +++ b/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment @@ -0,0 +1,37 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" + nickname="Paul" + subject="comment 4" + date="2014-08-24T11:53:11Z" + content=""" +@azul, thanks for hints, but it still fails. No wonders though - this is Haskell, kids. + +~~~~ +$ cabal install git-annex --only-dependencies +Resolving dependencies... +cabal: Could not resolve dependencies: +trying: git-annex-5.20140817 +trying: git-annex-5.20140817:+webapp +trying: git-annex-5.20140817:+s3 +trying: git-annex-5.20140817:+dns +trying: dns-1.4.3 +trying: yesod-1.2.6.1 +trying: yesod-auth-1.3.4.2 +trying: http-client-0.3.7.1 +trying: http-client-0.3.7.1:+network-uri +trying: hS3-0.5.8 +trying: hxt-9.3.1.6 +trying: hxt-9.3.1.6:-network-uri +rejecting: network-2.6.0.1, 2.6.0.0 (conflict: hxt-9.3.1.6:network-uri => +network>=2.4 && <2.6) +rejecting: network-2.5.0.0, 2.4.2.3, 2.4.2.2, 2.4.2.1, 2.4.2.0, 2.4.1.2, +2.4.1.1, 2.4.1.0, 2.4.0.1, 2.4.0.0, 2.3.2.0, 2.3.1.1, 2.3.1.0, 2.3.0.14, +2.3.0.13, 2.3.0.12, 2.3.0.11, 2.3.0.10, 2.3.0.9, 2.3.0.8, 2.3.0.7, 2.3.0.6, +2.3.0.5, 2.3.0.4, 2.3.0.3, 2.3.0.2, 2.3.0.1, 2.3 (conflict: +http-client-0.3.7.1:network-uri => network>=2.6) +rejecting: network-2.2.3.1, 2.2.3, 2.2.1.10, 2.2.1.9, 2.2.1.8, 2.2.1.7, +2.2.1.6, 2.2.1.5, 2.2.1.4, 2.2.1.3, 2.2.1.2, 2.2.1.1, 2.2.1, 2.2.0.1, 2.2.0.0, +2.1.0.0, 2.0 (conflict: dns => network>=2.3) +~~~~ + +"""]] From fcd8fe8c6cdb6f2330100350f68bae2521bc9a43 Mon Sep 17 00:00:00 2001 From: Ganwell Date: Sun, 24 Aug 2014 16:48:33 +0000 Subject: [PATCH 05/19] Added a comment: Project for Paul --- ...mment_3_f0270392af15f219a76add333316965f._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment new file mode 100644 index 0000000000..f65788e6b9 --- /dev/null +++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="Ganwell" + ip="46.14.43.36" + subject="Project for Paul" + date="2014-08-24T16:48:32Z" + content=""" +Hi Paul + +I just found a weekend project for you: rewrite git-annex in Python. Let me know when you're done. + +Best, Jean-Louis +"""]] From 98f52bbd4ac491a765869695d71ea5a5bbe9b718 Mon Sep 17 00:00:00 2001 From: Ganwell Date: Sun, 24 Aug 2014 17:43:30 +0000 Subject: [PATCH 06/19] removed --- ...mment_3_f0270392af15f219a76add333316965f._comment | 12 ------------ 1 file changed, 12 deletions(-) delete mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment deleted file mode 100644 index f65788e6b9..0000000000 --- a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="Ganwell" - ip="46.14.43.36" - subject="Project for Paul" - date="2014-08-24T16:48:32Z" - content=""" -Hi Paul - -I just found a weekend project for you: rewrite git-annex in Python. Let me know when you're done. - -Best, Jean-Louis -"""]] From ff138fc7c1d051b5b4a20c213427d25eee3385d0 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" Date: Sun, 24 Aug 2014 18:29:23 +0000 Subject: [PATCH 07/19] Added a comment --- ...mment_3_5605d42a68b3140cb660eb710ce5031e._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment new file mode 100644 index 0000000000..8e613dd211 --- /dev/null +++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" + nickname="Paul" + subject="comment 3" + date="2014-08-24T18:29:23Z" + content=""" +Sure, that's the plan. But first I'm doing my homework to understand how it got to that and how community copes with that. Maybe I don't get something and every open-source project should have a notice like: \"Installation from scratch. This is not recommended.\" (http://git-annex.branchable.com/install/). Interested in building software you run? Interested to help? Get lost, you won't get it. Am I surprised? Nope, I'm doing my homework and know where that Haskell thing came from. A piece of Microsoft was largely involved with it, so no surprise of such attitudes. + +Surely I'm not the only one who got jaundiced eye on git-annex: https://github.com/tv42/big : \"big is not like git-annex, because: it's not written in Haskell, so it might even work across distribution upgrades and platforms\". Certainly, stories of cvsup and unison, which are now where they should be - rest in peace, didn't help. So, once again, I'm interested to know how other people deal with this lack of proper compilation instructions, ability to get simple and easy tweaks, etc. - short of not using it, which seems to be a popular choice, despite all the git-annex coolness (I for one have been having its deployment in my queue fro half a year, instead of spending exactly a weekend to do tweaks I need and contribute them back). + + +"""]] From 291eaa50ba66de8b35b4991b560987a390c45938 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" Date: Sun, 24 Aug 2014 18:31:25 +0000 Subject: [PATCH 08/19] Added a comment --- .../comment_4_f56508164c71b2080150bc354e5de4b7._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment new file mode 100644 index 0000000000..8afa4c6fbc --- /dev/null +++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" + nickname="Paul" + subject="comment 4" + date="2014-08-24T18:31:25Z" + content=""" +Previous comment was written in response to a comment suggesting me to rewrite it in Python myself - which was then removed for some reason. + +"""]] From 51f129d9f48682518e33b713840980d85827d617 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" Date: Sun, 24 Aug 2014 19:59:38 +0000 Subject: [PATCH 09/19] --- ...__new__34___hash_formats_are_mixed_up.mdwn | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn new file mode 100644 index 0000000000..3933fcbbab --- /dev/null +++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn @@ -0,0 +1,28 @@ +~~~~ +$ git annex version +git-annex version: 5.20140818-g10bf03a +~~~~ + +When repository was initially created, it used "old" hashing from http://git-annex.branchable.com/internals/hashing/ . After some operations, annex was upgraded to "new" format. However, symlinks are still in "old" format and dangling. "git annex fsck", "git annex repair", "git annex pre-commit" - none helps. + +~~~~ +$ ls -l pics +lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22 2012 IMG_3776.JPG -> ../.git/annex/objects/KM/j6/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG +lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22 2012 renamed2.jpg -> ../.git/annex/objects/7F/z3/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG +lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22 2012 renamed.jpg -> ../.git/annex/objects/W1/vK/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG + +$ find .git/annex/objects/ +.git/annex/objects/ +.git/annex/objects/219 +.git/annex/objects/219/741 +.git/annex/objects/219/741/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG +.git/annex/objects/219/741/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG +.git/annex/objects/7a6 +.git/annex/objects/7a6/632 +.git/annex/objects/7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG +.git/annex/objects/7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG +.git/annex/objects/df3 +.git/annex/objects/df3/9a8 +.git/annex/objects/df3/9a8/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG +.git/annex/objects/df3/9a8/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG +~~~~ From 230eba2fd84109b4a3a73223346e5ea57f811c0b Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" Date: Sun, 24 Aug 2014 20:27:09 +0000 Subject: [PATCH 10/19] Added a comment --- ..._5ed3f7b21b007e269f5846cb2d805493._comment | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment new file mode 100644 index 0000000000..8ca81d3251 --- /dev/null +++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment @@ -0,0 +1,35 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" + nickname="Paul" + subject="comment 1" + date="2014-08-24T20:27:08Z" + content=""" +Aha, so local repo is created with old hash format. But when you add remote (special rsync remote in my case), and copy --to it, it uses new hashes: + +~~~~ +copy 20120122 Routing doorbell/IMG_3776.JPG (checking nas-rsync...) (to nas-rsync...) +sending incremental file list +7a6/ +7a6/632/ +7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/ +7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG +~~~~ + +This explains this nonsense: + +~~~~ +$ git annex unused --from=nas-rsync +unused nas-rsync (checking for unused data...) (checking master...) + Some annexed data on nas-rsync is not used by any files: + NUMBER KEY + 1 SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG + 2 SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG + 3 SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG + (To see where data was previously used, try: git log --stat -S'KEY') + + To remove unwanted data: git-annex dropunused --from nas-rsync NUMBER + +ok +~~~~ + +"""]] From 6cb0e971aaa2f2c3181082e3606b4aad1279020a Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" Date: Sun, 24 Aug 2014 22:26:47 +0000 Subject: [PATCH 11/19] Added a comment --- ...ment_2_436d8994457517e4c6f68f572b83decc._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment new file mode 100644 index 0000000000..192d48fc76 --- /dev/null +++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE" + nickname="Paul" + subject="comment 2" + date="2014-08-24T22:26:47Z" + content=""" +Ok, I see, http://git-annex.branchable.com/internals/hashing/ says that old vs new hash mess is deliberate, to make user experience better. (One might ask why one hash was replaced with another equivalent, but nobody would. Oh wait, it's a filesystem case sensitivity issue of course. But it's too secret to be mentioned on \"hashing\" page.) + +\"unused --from=\" issue comes and goes, don't see it now. That initial issue of completely broken symlinks happened after running testremote, then breaking it (because it should say it takes hour(s) to complete). So, many users probably won't be affected (nevermind that those who will, will essentially have data loss). + +Last issue I faced that somehow my local working copy gets \"bare = true\" each time I sync against remote SSH repo (which is bare of course, as remote repo should be). + +"""]] From 29f13435e56dfe01c1eb53462ec9f1150f49793c Mon Sep 17 00:00:00 2001 From: "https://launchpad.net/~electrichead" Date: Mon, 25 Aug 2014 15:51:00 +0000 Subject: [PATCH 12/19] Added a comment: Regarding accessing files in a time capsule... --- ...t_1_2614eb2e9b7b23fa9bb4251c0d025909._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment diff --git a/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment b/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment new file mode 100644 index 0000000000..dbe429fa9c --- /dev/null +++ b/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://launchpad.net/~electrichead" + nickname="electrichead" + subject="Regarding accessing files in a time capsule..." + date="2014-08-25T15:51:00Z" + content=""" +Imagine a rather contrived doomsday scenario: the file paths and/or basenames are important and, for some reason, the symlinks are not present (perhaps they got deleted, or aren't supported). `git` and `git-annex` no longer exist and let's assume knowledge of `git` internals is not useful here. All the *content* is there, stored under hashed file names under `.git/annex/objects`. + +I may be missing something obvious but I think options for restoring file paths include: + + - direct mode bypasses this issue; all the files are right there. + - the WORM backend perhaps carries enough information in the object file names to work with. + - file content/metadata may be sufficient to easily recreate a sensible directory structure in some cases, so no worries. + +These first two options may represent compromises in various use-cases and the last may not be applicable or, if it is, practical. The object-path mapping could trivially be backed up in plain text in lieu of these. Like I said, I may be overlooking something here that makes this unnecessary or even a non-concern (actually, I've convinced myself it's not a serious concern in most of the use-cases I've considered, but crossing i's and dotting t's). +"""]] From 940b92926f0ea8c8c5ad933b2eb74b60fa276a85 Mon Sep 17 00:00:00 2001 From: Hans_Ryding Date: Mon, 25 Aug 2014 16:16:34 +0000 Subject: [PATCH 13/19] Added a comment: Relying on path is not best practice in a Windows environment --- ..._0d7a4f740180dff7c0853062e4913804._comment | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment new file mode 100644 index 0000000000..42537f9f46 --- /dev/null +++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="Hans_Ryding" + ip="81.229.194.7" + subject="Relying on path is not best practice in a Windows environment" + date="2014-08-25T16:16:33Z" + content=""" +Unlike under POSIX environments +generally applications under windows don't add themselves to path, +or to a directory already in path. + +Generally applications announce their location using the registry. +Under either HKEY_LOCAL_MACHINE\SOFTWARE, +or in case of software installed for one particular user only +under HKEY_CURRENT_USER\SOFTWARE. + +Git however AFAIK does not. +Most likely the best thing to do is to prompt the user when installing git-annex +where git is, and store this variable. + +Note that in both my installs I installed git-annex into the git directory, +and the git-annex webapp still couldn't find it. +"""]] From f8c4d80aaa457192a76031b6a06b9f5d154c5890 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmBmv0HhwTFxkpxlf8ifTlMOHnIwHCHTYs" Date: Tue, 26 Aug 2014 12:18:39 +0000 Subject: [PATCH 14/19] Added a comment: path on windows --- .../comment_6_748aa921afee3d7e4667dee50e70a558._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment new file mode 100644 index 0000000000..4cbf0ea589 --- /dev/null +++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmBmv0HhwTFxkpxlf8ifTlMOHnIwHCHTYs" + nickname="y" + subject="path on windows" + date="2014-08-26T12:18:39Z" + content=""" +To add to my comment I also installed git-annex in the same directory as the msys git distrib in both cases. +"""]] From a9c714c94ade89752030d4b2baf5293efbe903bf Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkQTGU3IbXLfP449QbE9HwMWlNVRR4JD1k" Date: Tue, 26 Aug 2014 19:55:58 +0000 Subject: [PATCH 15/19] --- ...he_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn diff --git a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn new file mode 100644 index 0000000000..1f4f49842e --- /dev/null +++ b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn @@ -0,0 +1,3 @@ +I'm looking to use the Git-Annex Assistant to backup a single repository that is present on and synced between two computers (a home and a working computer). Ideally, each computer uses rsync.net for both of these service, while at the same time treating the cloud storage service as untrusted (so anything stored or tranferred through there is encrypted). Is it possible to do this using solely rsync.net (without the addition of some XMPP service)? According to the software, using shared encryption allows anyone with a clone of the repository to decrypt files on a remote, but the simplest way to make this clone seems to be to first clone to a removable drive, and then from the drive to the second computer (and then deleting the records of the clone to the drive). I'm unsure if by then setting up the backup at rsync.net for the second computer, whether the software will create a second backup that acts independently of the first, neglecting any syncing, or if it will recognize the backup as one of the same repository. I'm also unsure as to whether the software will even sync if the backup is recognized, or whether a tranfer repository at rsync.net is also necessary to complete the setup. Could you perhaps give me some advice on how to achieve this setup, or point me to some information that may help me along? + +(If the setup is unclear, I'm essentially trying to replicate something like SpiderOak with the Git-Annex Assistant, without using an XMPP service) From 8ef3269dc2a09fcd3ed5d8f79686d708e5497b08 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkQTGU3IbXLfP449QbE9HwMWlNVRR4JD1k" Date: Tue, 26 Aug 2014 20:17:53 +0000 Subject: [PATCH 16/19] --- ...the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn index 1f4f49842e..8d3c840246 100644 --- a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn +++ b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn @@ -1,3 +1,5 @@ I'm looking to use the Git-Annex Assistant to backup a single repository that is present on and synced between two computers (a home and a working computer). Ideally, each computer uses rsync.net for both of these service, while at the same time treating the cloud storage service as untrusted (so anything stored or tranferred through there is encrypted). Is it possible to do this using solely rsync.net (without the addition of some XMPP service)? According to the software, using shared encryption allows anyone with a clone of the repository to decrypt files on a remote, but the simplest way to make this clone seems to be to first clone to a removable drive, and then from the drive to the second computer (and then deleting the records of the clone to the drive). I'm unsure if by then setting up the backup at rsync.net for the second computer, whether the software will create a second backup that acts independently of the first, neglecting any syncing, or if it will recognize the backup as one of the same repository. I'm also unsure as to whether the software will even sync if the backup is recognized, or whether a tranfer repository at rsync.net is also necessary to complete the setup. Could you perhaps give me some advice on how to achieve this setup, or point me to some information that may help me along? (If the setup is unclear, I'm essentially trying to replicate something like SpiderOak with the Git-Annex Assistant, without using an XMPP service) + +[Edit: It may be easier to just use Git-Annex (no assistant), so that works too] From 9710e8c7ca8ddb244e6100ef736106f0db7af254 Mon Sep 17 00:00:00 2001 From: Ganwell Date: Tue, 26 Aug 2014 23:03:09 +0000 Subject: [PATCH 17/19] Added a comment: How I solved it... --- ...comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment new file mode 100644 index 0000000000..e58191a7f2 --- /dev/null +++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="Ganwell" + ip="178.174.3.166" + subject="How I solved it..." + date="2014-08-26T23:03:09Z" + content=""" +I decided it was a bit harsh, so I removed comment. Here is how I solved problem: + +I have a server without much storage which runs the git-annex process, the data is stored on the NAS mounted via iSCSI. I never even thought of trying to compile git-annex on a NAS. I did things like that many years ago and it used to much time, whether the language was, common or not, didn't change much. Missing floating point units on the NAS killed performance of the programms I wanted to run anyways. +"""]] From b58f790c0e12da5f6ba26297d0601bb2d18f7ce4 Mon Sep 17 00:00:00 2001 From: Ganwell Date: Tue, 26 Aug 2014 23:15:38 +0000 Subject: [PATCH 18/19] --- doc/todo/merge_in_ram___40__disk__41____63__.mdwn | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 doc/todo/merge_in_ram___40__disk__41____63__.mdwn diff --git a/doc/todo/merge_in_ram___40__disk__41____63__.mdwn b/doc/todo/merge_in_ram___40__disk__41____63__.mdwn new file mode 100644 index 0000000000..a4a698a720 --- /dev/null +++ b/doc/todo/merge_in_ram___40__disk__41____63__.mdwn @@ -0,0 +1,5 @@ +git-annex is great. But for my repos the merge and recording state operations take forever. + +(merging fotos_enc_pg/synced/git-annex into git-annex...) + +Since git-annex is another branch (than master) and git usually needs a worktree for merging I assume that git-annex branch is temporarily checked out somewhere. Would it be possible to move this operation to RAM? Or a RAM-Disk? From 63b0830497d64e104936551a061bfc4f12d54c29 Mon Sep 17 00:00:00 2001 From: "http://bret.io/" Date: Tue, 26 Aug 2014 23:30:07 +0000 Subject: [PATCH 19/19] Added visual bug description --- doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn diff --git a/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn b/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn new file mode 100644 index 0000000000..730df1d27f --- /dev/null +++ b/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn @@ -0,0 +1,12 @@ +### Please describe the problem. +When pairing with xmpp buddys, the well does not expand to fit the whole buddy list + +### What steps will reproduce the problem? +Go to the pairing menu + +### What version of git-annex are you using? On what operating system? + 5.20140717 from the homebrew bottle + +### Please provide any additional information below. + +![image of bug](http://i.imgur.com/fZe1ERD.png)