From c865b8b2eb58e6d75e87232b25862de9b258aa81 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 10 Jul 2014 18:11:22 +0000 Subject: Added a comment --- ...ent_1_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 000000000..c0455b992 --- /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? +"""]] -- cgit v1.2.3 From 496a75071293915587db1d2162ed59944d2b0a9a Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 10 Jul 2014 18:24:17 +0000 Subject: Added a comment --- ...ent_1_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 000000000..0359be528 --- /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. +"""]] -- cgit v1.2.3 From 4242dbd8e5aa73232a508620102f804e6ed72673 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 10 Jul 2014 18:48:17 +0000 Subject: 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 000000000..61c62703c --- /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. +"""]] -- cgit v1.2.3 From b4a5f1023507e8cdd2225a2fbea0895149e95eeb Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Thu, 10 Jul 2014 19:02:00 +0000 Subject: 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 000000000..d7d288b39 --- /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.. +"""]] -- cgit v1.2.3