From 67144b1c466c1262214b1d197c773dd79209ff6f Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Mon, 28 Sep 2020 19:44:08 +0000 Subject: [PATCH 1/7] Added a comment --- ...nt_9_7159b17d64ee147822969d79d5a1c48c._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_9_7159b17d64ee147822969d79d5a1c48c._comment diff --git a/doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_9_7159b17d64ee147822969d79d5a1c48c._comment b/doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_9_7159b17d64ee147822969d79d5a1c48c._comment new file mode 100644 index 0000000000..f8f9e7e6e5 --- /dev/null +++ b/doc/bugs/howto_guarantee_a_single_instance_of_a_special_remote__63__/comment_9_7159b17d64ee147822969d79d5a1c48c._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="yarikoptic" + avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4" + subject="comment 9" + date="2020-09-28T19:44:05Z" + content=""" +Sorry for being anal with my questions and not just trying it out... but by `The async extension to the protocol guarantees only a single process will be run.` which of the following scenarios do you mean + +- a. there will be no parallel workers if `--jobs N` is specified (thus a single process for an external remote) +- b. there are parallel workers, and a single instance of an external special remote will be ran and either + - b.1. only one worker would be able to talk to it + - b.2. parallel workers will talk to the same async external special remote + +or may be some other c. or b.3 ? +"""]] From 32cd9a44ca6949ab871a8a383010dcad9aa5ec3c Mon Sep 17 00:00:00 2001 From: "mark@6b90344cdab3158eacb94a3944460d138afc9bef" Date: Mon, 28 Sep 2020 21:09:27 +0000 Subject: [PATCH 2/7] --- ...git-annex_with_SourceTree_in_Catalina.mdwn | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina.mdwn diff --git a/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina.mdwn b/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina.mdwn new file mode 100644 index 0000000000..9020e0fad0 --- /dev/null +++ b/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina.mdwn @@ -0,0 +1,34 @@ +### Please describe the problem. +Historically (in older versions of MacOS) to get git-annex working with SourceTree I've done the following: + +When committing in SourceTree or SmartGit after adding annex, you may get error "git: 'annex' is not a git command". To fix: +First make sure your client is using the system git +In SourceTree preferences, go to Git tab and use system git (likely in /usr/bin/git) +Disable SIP (needed step starting from Mac OSX El Capitan), by doing the following: +Restart your Mac. +Then, make a symbolic link so SourceTree/SmartGit can see git-annex (look at which git-annex to find real location): +sudo ln -s /usr/local/bin/git-annex /usr/bin/git-annex +Re-enable SIP, by following the same steps for disabling, but rather issuing the command csrutil enable in the Terminal window + +But now, I still can't write the symbolic link with SIP disabled. Obviously this isn't git-annex's fault. But I cannot figure out how to integrate git-annex so that SourceTree can work with it. + +### What steps will reproduce the problem? +See above. + +### What version of git-annex are you using? On what operating system? +git-annex version: 8.20200908 +macOS 10.15.6 + +### 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. +"""]] + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + + From a8e4539d156ba58801c8a9ae1a42b393671cfd46 Mon Sep 17 00:00:00 2001 From: "mark@6b90344cdab3158eacb94a3944460d138afc9bef" Date: Mon, 28 Sep 2020 21:10:58 +0000 Subject: [PATCH 3/7] Added a comment --- .../comment_1_ebf44f50f952a87d1af06ea24877baae._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina/comment_1_ebf44f50f952a87d1af06ea24877baae._comment diff --git a/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina/comment_1_ebf44f50f952a87d1af06ea24877baae._comment b/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina/comment_1_ebf44f50f952a87d1af06ea24877baae._comment new file mode 100644 index 0000000000..2bfea18452 --- /dev/null +++ b/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina/comment_1_ebf44f50f952a87d1af06ea24877baae._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="mark@6b90344cdab3158eacb94a3944460d138afc9bef" + nickname="mark" + avatar="http://cdn.libravatar.org/avatar/780625d9a11f1840abd94822dfe3e9f5" + subject="comment 1" + date="2020-09-28T21:10:56Z" + content=""" +And BTW, we really value git-annex and use it for keeping all of our golden reference outputs for regression testing in place and available for others who need to run tests. +"""]] From 26842956b583a8b5127b3b9ea3e7de4219559505 Mon Sep 17 00:00:00 2001 From: "mark@6b90344cdab3158eacb94a3944460d138afc9bef" Date: Mon, 28 Sep 2020 21:40:23 +0000 Subject: [PATCH 4/7] Added a comment --- ...omment_2_c3a86ef4972b1a2db985fd03750aa449._comment | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina/comment_2_c3a86ef4972b1a2db985fd03750aa449._comment diff --git a/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina/comment_2_c3a86ef4972b1a2db985fd03750aa449._comment b/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina/comment_2_c3a86ef4972b1a2db985fd03750aa449._comment new file mode 100644 index 0000000000..8585de6df5 --- /dev/null +++ b/doc/bugs/Cannot_integrate_git-annex_with_SourceTree_in_Catalina/comment_2_c3a86ef4972b1a2db985fd03750aa449._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="mark@6b90344cdab3158eacb94a3944460d138afc9bef" + nickname="mark" + avatar="http://cdn.libravatar.org/avatar/780625d9a11f1840abd94822dfe3e9f5" + subject="comment 2" + date="2020-09-28T21:40:21Z" + content=""" +Switching SourceTree to look at /usr/local/git/bin fixed the problem. + +This can be CLOSED. +"""]] From ff0784dad99928c669e7b286a2a12744a15d1f8a Mon Sep 17 00:00:00 2001 From: "lykos@d125a37d89b1cfac20829f12911656c40cb70018" Date: Tue, 29 Sep 2020 08:32:22 +0000 Subject: [PATCH 5/7] Added a comment --- ...3_bc674213e07d4518d37834bf4b771807._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/todo/CHECKPRESENT-MULTI/comment_3_bc674213e07d4518d37834bf4b771807._comment diff --git a/doc/todo/CHECKPRESENT-MULTI/comment_3_bc674213e07d4518d37834bf4b771807._comment b/doc/todo/CHECKPRESENT-MULTI/comment_3_bc674213e07d4518d37834bf4b771807._comment new file mode 100644 index 0000000000..a25355436a --- /dev/null +++ b/doc/todo/CHECKPRESENT-MULTI/comment_3_bc674213e07d4518d37834bf4b771807._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="lykos@d125a37d89b1cfac20829f12911656c40cb70018" + nickname="lykos" + avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2" + subject="comment 3" + date="2020-09-29T08:32:20Z" + content=""" +I agree about the simplification. However, when resuming an upload with, say, 400 chunks where only 10 are missing, after CHECKPRESENT-MULTI-FAILURE, we'd need to CHECKPRESENT another 390 keys until we can continue. Sure, the remote could cache the replies, but another idea would be for the remote to reply with the last key in the list that is present. + +Example: + +``` +$ CHECKPRESENT-MULTI a b c d e # git annex calls CHECKPRESENT-MULTI with an ordered list +CHECKPRESENT-MULTI-SUCCESS # all keys are present +CHECKPRESENT-MULTI-FAILURE # all keys are missing +CHECKPRESENT-MULTI-FAILURE c # a, b and c are present. Rest ist missing +``` +"""]] From 7b37f2288032519efa106f74f5632e3bd6e53ba7 Mon Sep 17 00:00:00 2001 From: "lykos@d125a37d89b1cfac20829f12911656c40cb70018" Date: Tue, 29 Sep 2020 08:36:19 +0000 Subject: [PATCH 6/7] Added a comment --- ..._5228016c35ca0b13545b82bbd3b9455e._comment | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment diff --git a/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment b/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment new file mode 100644 index 0000000000..04c5c71316 --- /dev/null +++ b/doc/todo/CHECKPRESENT-MULTI/comment_4_5228016c35ca0b13545b82bbd3b9455e._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="lykos@d125a37d89b1cfac20829f12911656c40cb70018" + nickname="lykos" + avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2" + subject="comment 4" + date="2020-09-29T08:36:18Z" + content=""" + +I agree about the simplification. However, when resuming an upload with, say, 400 chunks where only 10 are missing, after CHECKPRESENT-MULTI-FAILURE, we'd need to CHECKPRESENT another 390 keys until we can continue. Sure, the remote could cache the replies, but another idea would be for the remote to reply with the last key in the list that is present. + +Example: + +``` +$ CHECKPRESENT-MULTI a b c d e # git annex calls CHECKPRESENT-MULTI with an ordered list +CHECKPRESENT-MULTI-SUCCESS # all keys are present +CHECKPRESENT-MULTI-FAILURE # all keys are missing +CHECKPRESENT-MULTI-FAILURE c # Everything up to c is present, d is missing. e could be present or missing +``` + +"""]] From a3083436dce98abe24dbfc0cf38d33e06d98a57e Mon Sep 17 00:00:00 2001 From: "lykos@d125a37d89b1cfac20829f12911656c40cb70018" Date: Tue, 29 Sep 2020 08:36:37 +0000 Subject: [PATCH 7/7] removed --- ...3_bc674213e07d4518d37834bf4b771807._comment | 18 ------------------ 1 file changed, 18 deletions(-) delete mode 100644 doc/todo/CHECKPRESENT-MULTI/comment_3_bc674213e07d4518d37834bf4b771807._comment diff --git a/doc/todo/CHECKPRESENT-MULTI/comment_3_bc674213e07d4518d37834bf4b771807._comment b/doc/todo/CHECKPRESENT-MULTI/comment_3_bc674213e07d4518d37834bf4b771807._comment deleted file mode 100644 index a25355436a..0000000000 --- a/doc/todo/CHECKPRESENT-MULTI/comment_3_bc674213e07d4518d37834bf4b771807._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="lykos@d125a37d89b1cfac20829f12911656c40cb70018" - nickname="lykos" - avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2" - subject="comment 3" - date="2020-09-29T08:32:20Z" - content=""" -I agree about the simplification. However, when resuming an upload with, say, 400 chunks where only 10 are missing, after CHECKPRESENT-MULTI-FAILURE, we'd need to CHECKPRESENT another 390 keys until we can continue. Sure, the remote could cache the replies, but another idea would be for the remote to reply with the last key in the list that is present. - -Example: - -``` -$ CHECKPRESENT-MULTI a b c d e # git annex calls CHECKPRESENT-MULTI with an ordered list -CHECKPRESENT-MULTI-SUCCESS # all keys are present -CHECKPRESENT-MULTI-FAILURE # all keys are missing -CHECKPRESENT-MULTI-FAILURE c # a, b and c are present. Rest ist missing -``` -"""]]