From 50781a4a5f6a98f6c1cf111cb0537d81ec73ab2c Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 10 Jul 2014 18:11:22 +0000 Subject: [PATCH 1/4] Added a comment --- ..._be1302a006a66e501fe543f3af191fea._comment | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment diff --git a/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment b/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment new file mode 100644 index 0000000000..c0455b9924 --- /dev/null +++ b/doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.2" + subject="comment 1" + date="2014-07-10T18:11:22Z" + content=""" +The most likely problem would be if your repository contained annexed objects owned by different user than the one running `git annex direct`. + +However, I cannot reproduce this problem: + +
+direct foo 
+  /home/joey/tmp/r/.git/annex/objects/pV/7j/SHA256E-s30--2754b7f82f6994005b97256273756f14d4abc17165c8819c06c07340d03351fa: setFileMode: permission denied (Operation not permitted)
+
+  leaving this file as-is; correct this problem and run git annex fsck on it
+direct  ok
+
+ +Since version 4.20130921, any exception when moving a file to direct mode should be caught like that. + +I will need more information to reproduce your bug. Or are you sure you wrote down the right version of git-annex? +"""]] From fc48c3bb23d66c93ced2d73c74348b38983827fc Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 10 Jul 2014 18:24:17 +0000 Subject: [PATCH 2/4] Added a comment --- ..._053b12e8b412723ff1d6b4e64e71af9e._comment | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/bugs/gpg_does_not_ask_for_password_inside_tmux/comment_1_053b12e8b412723ff1d6b4e64e71af9e._comment diff --git a/doc/bugs/gpg_does_not_ask_for_password_inside_tmux/comment_1_053b12e8b412723ff1d6b4e64e71af9e._comment b/doc/bugs/gpg_does_not_ask_for_password_inside_tmux/comment_1_053b12e8b412723ff1d6b4e64e71af9e._comment new file mode 100644 index 0000000000..0359be5287 --- /dev/null +++ b/doc/bugs/gpg_does_not_ask_for_password_inside_tmux/comment_1_053b12e8b412723ff1d6b4e64e71af9e._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.2" + subject="comment 1" + date="2014-07-10T18:24:17Z" + content=""" +I cannot reproduce this. I made sure to unset `GPG_AGENT_INFO` so gpg would need to prompt for a password on the terminal, and it did. + +
+joey@darkstar:~/tmp/r>unset GPG_AGENT_INFO 
+joey@darkstar:~/tmp/r>git annex copy --to remote
+copy n/xxx (gpg) 
+You need a passphrase to unlock the secret key for
+user: \"Joey Hess \"
+4096-bit RSA key, ID 17065459, created 2009-06-17 (main key ID 2512E3C7)
+
+gpg: gpg-agent is not available in this session
+Enter passphrase: 
+
+ +I cannot think of anything that would make gpg's password prompting behave differently inside tmux than outside, either. + +I think that to debug this, you are going to need to look at what the gpg process is trying to do. +"""]] From 4f62105aa34ac2b3330431a9ce632cd695ad7559 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 10 Jul 2014 18:48:17 +0000 Subject: [PATCH 3/4] Added a comment --- ...comment_1_f32fbae29e4db039804c0853256c238c._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_1_f32fbae29e4db039804c0853256c238c._comment diff --git a/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_1_f32fbae29e4db039804c0853256c238c._comment b/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_1_f32fbae29e4db039804c0853256c238c._comment new file mode 100644 index 0000000000..61c62703c6 --- /dev/null +++ b/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_1_f32fbae29e4db039804c0853256c238c._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.2" + subject="comment 1" + date="2014-07-10T18:48:17Z" + content=""" +Reproduced. `git annex sync --content` has the same problem. + +Of course, both it and the assistant *do* check if files can be dropped. For some reason, it is deciding it is not safe to drop the file. +"""]] From 56b2b49440c634ce0f60ceed352f1f1ebc8d8154 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 10 Jul 2014 19:02:00 +0000 Subject: [PATCH 4/4] Added a comment: user misconfiguration --- ...comment_2_405bfa00dfd433352c263afe75e94b2c._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_2_405bfa00dfd433352c263afe75e94b2c._comment diff --git a/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_2_405bfa00dfd433352c263afe75e94b2c._comment b/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_2_405bfa00dfd433352c263afe75e94b2c._comment new file mode 100644 index 0000000000..d7d288b39d --- /dev/null +++ b/doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_2_405bfa00dfd433352c263afe75e94b2c._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.2" + subject="user misconfiguration" + date="2014-07-10T19:02:00Z" + content=""" +Reason is simple: You manually put the repository into the source group, but its preferred content is not set to \"standard\". No matter what group a repository is in, you have to set its preferred content to something, or git-annex will default to assuming you want the repo to retain all files. + +So, `git annex wanted mintcream standard` and away you go. You'll also want to set that for the other 2 repos probably.. +"""]]