summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2014-07-10 15:02:30 -0400
committerGravatar Joey Hess <joey@kitenet.net>2014-07-10 15:02:30 -0400
commitdc2e10df07d2b694e66760c557dc85de8f47807c (patch)
tree558070a5437c610402aedc306c0fd1d5aca1f4bb
parentab644669b697136ffec4f01c78048db782dc398a (diff)
parentb4a5f1023507e8cdd2225a2fbea0895149e95eeb (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_1_f32fbae29e4db039804c0853256c238c._comment10
-rw-r--r--doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_2_405bfa00dfd433352c263afe75e94b2c._comment10
-rw-r--r--doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment22
-rw-r--r--doc/bugs/gpg_does_not_ask_for_password_inside_tmux/comment_1_053b12e8b412723ff1d6b4e64e71af9e._comment24
4 files changed, 66 insertions, 0 deletions
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.
+"""]]
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..
+"""]]
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:
+
+<pre>
+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
+</pre>
+
+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?
+"""]]
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.
+
+<pre>
+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 <joeyh@debian.org>\"
+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:
+</pre>
+
+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.
+"""]]