summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/bugs/cannot_remove___96__.t__96___directory.mdwn34
-rw-r--r--doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn39
-rw-r--r--doc/forum/Git_annex_hangs/comment_7_f3ea42dc6699275143ba44e7f57e7d5e._comment15
-rw-r--r--doc/forum/Move_files_in_git_annex___40__direct_mode__41__.mdwn22
-rw-r--r--doc/forum/Syncing_Compressed_files.mdwn1
-rw-r--r--doc/preferred_content/comment_10_d9eb7d8efe731cbcdb456fc56935d886._comment12
-rw-r--r--doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn5
7 files changed, 128 insertions, 0 deletions
diff --git a/doc/bugs/cannot_remove___96__.t__96___directory.mdwn b/doc/bugs/cannot_remove___96__.t__96___directory.mdwn
new file mode 100644
index 000000000..3c2b1aad7
--- /dev/null
+++ b/doc/bugs/cannot_remove___96__.t__96___directory.mdwn
@@ -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?
+
diff --git a/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn b/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn
new file mode 100644
index 000000000..5f3d0a6b1
--- /dev/null
+++ b/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn
@@ -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]]
diff --git a/doc/forum/Git_annex_hangs/comment_7_f3ea42dc6699275143ba44e7f57e7d5e._comment b/doc/forum/Git_annex_hangs/comment_7_f3ea42dc6699275143ba44e7f57e7d5e._comment
new file mode 100644
index 000000000..336a4ee05
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_7_f3ea42dc6699275143ba44e7f57e7d5e._comment
@@ -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.
+"""]]
diff --git a/doc/forum/Move_files_in_git_annex___40__direct_mode__41__.mdwn b/doc/forum/Move_files_in_git_annex___40__direct_mode__41__.mdwn
new file mode 100644
index 000000000..7974a3e42
--- /dev/null
+++ b/doc/forum/Move_files_in_git_annex___40__direct_mode__41__.mdwn
@@ -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`
diff --git a/doc/forum/Syncing_Compressed_files.mdwn b/doc/forum/Syncing_Compressed_files.mdwn
new file mode 100644
index 000000000..dd2f5adea
--- /dev/null
+++ b/doc/forum/Syncing_Compressed_files.mdwn
@@ -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?
diff --git a/doc/preferred_content/comment_10_d9eb7d8efe731cbcdb456fc56935d886._comment b/doc/preferred_content/comment_10_d9eb7d8efe731cbcdb456fc56935d886._comment
new file mode 100644
index 000000000..c7a898c68
--- /dev/null
+++ b/doc/preferred_content/comment_10_d9eb7d8efe731cbcdb456fc56935d886._comment
@@ -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?
+"""]]
diff --git a/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn b/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn
new file mode 100644
index 000000000..c0e5e9fb8
--- /dev/null
+++ b/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn
@@ -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).