mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2014-07-10 15:02:30 -04:00
commit b9892e2344
4 changed files with 66 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_1_f32fbae29e4db039804c0853256c238c._comment Normal file
View file

@ -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.
"""]]

10
doc/bugs/Assistant_doesn__39__t_check_if_it_can_drop_files/comment_2_405bfa00dfd433352c263afe75e94b2c._comment Normal file
View file

@ -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..
"""]]

22
doc/bugs/direct_mode_fails__44___left_in_an_inconsistent_state/comment_1_be1302a006a66e501fe543f3af191fea._comment Normal file
View file

@ -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?
"""]]

24
doc/bugs/gpg_does_not_ask_for_password_inside_tmux/comment_1_053b12e8b412723ff1d6b4e64e71af9e._comment Normal file
View file

@ -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.
"""]]