From 64478a1f201635c72044cfe78785ca704a57cfa3 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnDx6KWBl4PpP7qikNB7rp0hK_UvwQq_L0" <@web> Date: Wed, 5 Nov 2014 16:50:58 +0000 Subject: [PATCH 1/6] --- ...m_remote_repos_that_it_shouldn__39__t.mdwn | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn new file mode 100644 index 0000000000..4a7ac821ac --- /dev/null +++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn @@ -0,0 +1,37 @@ +### Please describe the problem. + +git-annex assistant starts to drop files in remote repos, even when they are set to manual. + +### What steps will reproduce the problem? + + +Create 3 repos: + +* A -- standard, archive +* m1 -- standard, manual +* m2 -- standard, manual + +System has 3 files annexed: file1, file2, file3. Repo "A" has all three files, m1 has none, m2 has file3. + +So, while in m1: + + m1 $ git annex find --want-drop --in m2 + file3 + +file3 shouln't be dropped from m2. There is no reason to do this. m2 is set as manual, and it shouldn't be touched in any case. + +Now, let's get this file in m1: + + m1 $ git annex get file3 + get file3 (from m2...) ok + (Recording state in git...) + m1 $ git annex find --want-drop --in m2 + +So when 'file3' is present in local repo, it's not going to be dropped from m2. + +I guess that rule 'present' works in local repo context while 'drop' acts on remote files. + + +### What version of git-annex are you using? On what operating system? + +I'm using latest version in Debian Jessie (5.20141024). From 8d8b2486c88acdfc2dbe6811f2d36b4901e1f266 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnDx6KWBl4PpP7qikNB7rp0hK_UvwQq_L0" <@web> Date: Wed, 5 Nov 2014 16:51:29 +0000 Subject: [PATCH 2/6] removed --- ..._4599023aa31ac3767a9c57b91b500f8d._comment | 35 ------------------- 1 file changed, 35 deletions(-) delete mode 100644 doc/preferred_content/comment_11_4599023aa31ac3767a9c57b91b500f8d._comment diff --git a/doc/preferred_content/comment_11_4599023aa31ac3767a9c57b91b500f8d._comment b/doc/preferred_content/comment_11_4599023aa31ac3767a9c57b91b500f8d._comment deleted file mode 100644 index bb96ec0d39..0000000000 --- a/doc/preferred_content/comment_11_4599023aa31ac3767a9c57b91b500f8d._comment +++ /dev/null @@ -1,35 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnDx6KWBl4PpP7qikNB7rp0hK_UvwQq_L0" - nickname="Александр" - subject="Dropping files from remotes" - date="2014-11-05T16:09:54Z" - content=""" -I think I found a bug where git-annex assistant starts to drop files in remote repos when it shouldn't. It can be easily reproduced with latest version in Debian Jessy (5.20141024) like this: - -Create 3 repos: - -* A -- standard, archive -* m1 -- standard, manual -* m2 -- standard, manual - -System has 3 files annexed: file1, file2, file3. Repo \"A\" has all three files, m1 has none, m2 has file3. - -So, while in m1: - - m1 $ git annex find --want-drop --in m2 - file3 - -file3 shouln't be dropped from m2. There is no reason to do this. m2 is set as manual, and it shouldn't be touched in any case. - -Now, let's get this file in m1: - - m1 $ git annex get file3 - get file3 (from m2...) ok - (Recording state in git...) - m1 $ git annex find --want-drop --in m2 - -So when 'file3' is present in local repo, it's not going to be dropped from m2. - -I guess that rule 'present' works in local repo context while 'drop' acts on remote files. - -"""]] From 24c915cabce95675e89e1934a7fa6a792f8c493b Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnDx6KWBl4PpP7qikNB7rp0hK_UvwQq_L0" <@web> Date: Wed, 5 Nov 2014 19:27:36 +0000 Subject: [PATCH 3/6] --- ...nt_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn index 4a7ac821ac..9ae870b6c4 100644 --- a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn +++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t.mdwn @@ -34,4 +34,4 @@ I guess that rule 'present' works in local repo context while 'drop' acts on rem ### What version of git-annex are you using? On what operating system? -I'm using latest version in Debian Jessie (5.20141024). +I'm using latest version in Debian Jessie (5.20141024) on amd64 and armhf. I've also reproduced the bug with manually compiled 5.20141105-g8d8b248 on amd64. From ce8ad8475ec28563641f972d6b74280eeae6878e Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw" Date: Wed, 5 Nov 2014 20:41:37 +0000 Subject: [PATCH 4/6] Added a comment --- .../comment_1_206f701fd80c5272e3e5627ec5621aab._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/news/version_5.20141125/comment_1_206f701fd80c5272e3e5627ec5621aab._comment diff --git a/doc/news/version_5.20141125/comment_1_206f701fd80c5272e3e5627ec5621aab._comment b/doc/news/version_5.20141125/comment_1_206f701fd80c5272e3e5627ec5621aab._comment new file mode 100644 index 0000000000..3e4f6b4078 --- /dev/null +++ b/doc/news/version_5.20141125/comment_1_206f701fd80c5272e3e5627ec5621aab._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw" + nickname="Carl" + subject="comment 1" + date="2014-11-05T20:41:37Z" + content=""" +It is a slightly peculiar version number, is it not? +"""]] From eac8047dad2a35d8cc01e1b7b5df7031c277dfc4 Mon Sep 17 00:00:00 2001 From: "https://olivier.mehani.name/" Date: Wed, 5 Nov 2014 22:57:21 +0000 Subject: [PATCH 5/6] Added a comment --- ...4_45e3b7094d0611b2e082be352f74151a._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/special_remotes/webdav/comment_14_45e3b7094d0611b2e082be352f74151a._comment diff --git a/doc/special_remotes/webdav/comment_14_45e3b7094d0611b2e082be352f74151a._comment b/doc/special_remotes/webdav/comment_14_45e3b7094d0611b2e082be352f74151a._comment new file mode 100644 index 0000000000..c7c2aafb06 --- /dev/null +++ b/doc/special_remotes/webdav/comment_14_45e3b7094d0611b2e082be352f74151a._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="https://olivier.mehani.name/" + nickname="olivier-mehani" + subject="comment 14" + date="2014-11-05T22:57:21Z" + content=""" +I have a similar problem to Maarten's, with some potential differences: +* The WebDAV server is actually an ownCloud 7 instance; +* The WebDAV server's SSL cert is issued by CAcert (whose root keys are otherwise installed on my system); +* The cetificate lists the WebDAV VHost's name as an Subject Alt Name rather than its Common Name. + + $ WEBDAV_USERNAME=shtrom WEBDAV_PASSWORD=correcthorsebatterystaple git annex initremote owncloud type=webdav url=https://owncloud/remote.php/webdav/annexdav chunk=10mb encryption=none + initremote owncloud (testing WebDAV server...) + git-annex: WebDAV failed to write file: TlsException (HandshakeFailed (Error_Protocol (\"certificate rejected: [NameMismatch \\"owncloud\\"]\",True,CertificateUnknown))): user error +failed + git-annex: initremote: 1 failed + +"""]] From 4a20e4cb49fef6617b06531b1484771a39c1c270 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawktbkKjilg70XC9XBFpIgVhtfLYH-0UMHY" Date: Thu, 6 Nov 2014 15:39:12 +0000 Subject: [PATCH 6/6] Added a comment --- ...t_2_bf5e13a490e16943acd2732f093695fc._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/forum/Using_git-annex/comment_2_bf5e13a490e16943acd2732f093695fc._comment diff --git a/doc/forum/Using_git-annex/comment_2_bf5e13a490e16943acd2732f093695fc._comment b/doc/forum/Using_git-annex/comment_2_bf5e13a490e16943acd2732f093695fc._comment new file mode 100644 index 0000000000..97ec4fb98e --- /dev/null +++ b/doc/forum/Using_git-annex/comment_2_bf5e13a490e16943acd2732f093695fc._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawktbkKjilg70XC9XBFpIgVhtfLYH-0UMHY" + nickname="Tad" + subject="comment 2" + date="2014-11-06T15:39:12Z" + content=""" +Ok so when I create my origin and after I add files to it, when I run git annex sync I get + +Invalid command: 'git-annex-shell 'configlist' '/~/gitfile.git'' + You appear to be using ssh to clone a git:// URL. + Make sure your core.gitProxy config option and the + GIT_PROXY_COMMAND environment variable are NOT set. +warning: no common commits + +and then it hangs. Is git-annex not accepting git via ssh? +"""]]