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

This commit is contained in:
Joey Hess 2016-01-28 12:36:26 -04:00
commit c7a89ead3a
Failed to extract signature
7 changed files with 128 additions and 0 deletions

View file

@ -0,0 +1,34 @@
### Please describe the problem.
I am running `git-annex test`, it stops on an NFS mount with exhausted resources (too many open FDs).
Then I try to remove the `.t` directory with `rm -rf .t` and get many errors like:
```
rm: cannot remove `.t/tmprepo61/.git/annex/objects/96/qw/SHA256E-s10--bcc2eba25d48be76c9d968f2d818196b0e10e13476dcff75371fc0ca4910450c/SHA256E-s10--bcc2eba25d48be76c9d968f2d818196b0e10e13476dcff75371fc0ca4910450c': Permission denied
```
The permissions on those files look normal (they are mine).
### What steps will reproduce the problem?
see above
### What version of git-annex are you using? On what operating system?
git HEAD (self-built). On Linux.
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
On /tmp the self-test works. Maybe it is related to NFS?

View file

@ -0,0 +1,39 @@
### Please describe the problem.
with previous snapshot (6.20160119+gitgb2a2f5d-1~ndall+1) you just get a clean output
[[!format sh """
hopa:~/.tmp
$> git clone /home/yoh/.tmp/datalad_temp_clone_url_RmXPyt 123
Cloning into '123'...
done.
$> cd 123
INFO.txt test-annex.dat@ test.dat
$> git annex lookupkey test-annex.dat
SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
"""]]
with new one (6.20160126+gitg65f4442-1~ndall+1) you get it polluted in such a freshly cloned repo with
[[!format sh """
$> git annex lookupkey test-annex.dat
(merging origin/git-annex into git-annex...)
(recording state in git...)
SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
"""]]
and since I am a "dude" who likes "devnulling" things for some reason (I hope reason is clear here ;)):
[[!format sh """
$> git annex lookupkey test-annex.dat 2>/dev/null
(merging origin/git-annex into git-annex...)
(recording state in git...)
SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
"""]]
I guess I will just skip all lines starting with ( for now but thought to let you know about such changed behavior which might complicate pipelining etc
[[!meta author=yoh]]

View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="parmour@1304ead3ef9008fa9fe66af7c8678dec867328da"
nickname="parmour"
subject="Similar sounding issue"
date="2016-01-28T15:02:31Z"
content="""
I have seen a similar sounding version on Centos 6.5. I had git version 2.6.4 and installed git annex using:
wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh epel-release-6-8.noarch.rpm
yum install git-annex
git annex would hang when running 'git annex add'
When I changed the git version to be 1.7.1 this problem went away. So it is something to do with the combination of client git version and git annex version.
"""]]

View file

@ -0,0 +1,22 @@
Hi guys, I have a git annex repo under `/path`.
I ran:
```
cd /path/subdir2
mv ../subdir1/stuff* .
git annex add
git annex sync
```
Then I went to another repo (clone of the first) and did:
```
cd /paht1
git annex sync
git annex get .
```
Now I got the stuff from under `subdir2` in my second repo, just that the same stuff is also still under `subdir1` - how do I make git-annex aware of this change?
Also, someone suggested running `git annex watch`

View file

@ -0,0 +1 @@
I don't see anywhere in the documentation that specifies this, but git-annex hasn't been syncing any kind of compressed file for me like zip files or 7z compressed files. Haven't tried gzip files. It has been working fine with other files like PDFs, video, images etc. Was wanting to know if that is expected behaviour or if something is wrong?

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
nickname="grawity"
subject="default settings?"
date="2016-01-28T09:32:45Z"
content="""
Could you clarify how the _default_ (empty) preferred content setting works? Is it equivalent to `anything`, or more magical than that?
(Asking because I noticed that `annex find --in . --want-drop` in such a repo matches basically all files, even the ones that `annex sync --content` just retrieved. Likewise, it retrieves files while `annex find --not --in . --want-get` lists nothing. I'm fine with the sync behavior here, but somewhat worried that a _future_ `annex sync --content` would actually decide to drop everything... I'm running 6.20160126 with numcopies=1.)
Also, what happens if I use `standard` for a repo that's not in any group?
"""]]

View file

@ -0,0 +1,5 @@
Please pull branch `patch-1` from repo
https://github.com/ggreif/git-annex.git
It contains some cleanups from warnings that appear with GHC 7.11 (and probably 8.0 too).