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

7 files changed, 98 insertions, 0 deletions

diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment
new file mode 100644
index 000000000..9fadf817f
--- /dev/null
+++ b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-06T15:11:18Z"
+ content="""
+There might be a general problem with using git-annex against a read-only filesystem, but the specific case here is a read-only filesystem containing a repository in an old format which git-annex needs to upgrade to the current format to use. So it's pretty reasonable that the (automatic) upgrade fails, since it's not being allowed to write to the repository to upgrade it.
+
+Now, if that repository is a indirect mode repo, there is really no change between version 3 and version 5, so it might do to let git-annex ignore the failure to write out the config, and treat that repo as if it's a v5 repo. It seems easier in most cases to mount the media read-write for git-annex to do the upgrade though.
+"""]]
diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment
new file mode 100644
index 000000000..4bd0bce59
--- /dev/null
+++ b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 2"
+ date="2014-10-06T15:18:20Z"
+ content="""
+i've seen problems like this not related to upgrades at all, in [[todo/read-only removable drives]]. furthermore, it seems to me that failure to upgrade a repository shouldn't be fatal and we should be able to recover and get files anyways, in the spirit of [[backwards compatibility|future_proofing]]. --[[anarcat]]
+"""]]
diff --git a/doc/bugs/git_clone_ignores_annex/comment_1_18ba05c51f82ddadd2558f6cd789e394._comment b/doc/bugs/git_clone_ignores_annex/comment_1_18ba05c51f82ddadd2558f6cd789e394._comment
new file mode 100644
index 000000000..e0b69f81a
--- /dev/null
+++ b/doc/bugs/git_clone_ignores_annex/comment_1_18ba05c51f82ddadd2558f6cd789e394._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-06T15:42:26Z"
+ content="""
+Making that symlink is extremely unsafe! git-annex will see two repositories. So if a file is present in the annex, with only one actual copy existing, and you try to drop it, git-annex will go check the other repository, find the file there, assume this means there's an extra copy and so proceed with the drop. Which deletes the only existing copy of your file. So if you do this, you will likely eventually lose data.
+
+However, recent versions of git-annex will detect if you clone a git repository with `--shared` and automatically hard link files into the annex when getting them into that repository. They also mark the shared clone as untrusted, to avoid the above problem. This is a much better solution.
+"""]]
diff --git a/doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_1_875ca12936d4b4505f2e280a454fe558._comment b/doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_1_875ca12936d4b4505f2e280a454fe558._comment
new file mode 100644
index 000000000..535c20e4d
--- /dev/null
+++ b/doc/bugs/modified_permissions_persist_after_unlock__44___commit/comment_1_875ca12936d4b4505f2e280a454fe558._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-06T15:47:39Z"
+ content="""
+I am unable to reproduce any problem with the steps you gave. I don't see any typechange message, and would not expect one. Perhaps your repository is lacking a .git/hooks/pre-commit script to run git-annex when you use `git commit -a`?
+
+It's not clear to me what problem you experienced, beyond the typechange message that I don't see.
+
+> git unlock test.txt (corrects and retains both versions)
+
+I don't understand that line at all. `git unlock` is not a valid git command, and what does \"corrects and retains both versions\" mean?
+
+Please provide an actual trascript of the problem, rather than the unclear description.
+"""]]
diff --git a/doc/forum/Broken_symlinks_remain_after_drop/comment_1_d4a59b9e58d43d7a3d437e521dd5c4e1._comment b/doc/forum/Broken_symlinks_remain_after_drop/comment_1_d4a59b9e58d43d7a3d437e521dd5c4e1._comment
new file mode 100644
index 000000000..33a9cb058
--- /dev/null
+++ b/doc/forum/Broken_symlinks_remain_after_drop/comment_1_d4a59b9e58d43d7a3d437e521dd5c4e1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-06T15:30:54Z"
+ content="""
+git-annex is behaving as expected here. The broken symlink allows you to run `git annex get` on it to get the file content back into the repository, or `git mv` to rename the file even though its content is not present, etc.
+
+You can probably accomplish what you want by using git branches. You want a branch for repo2 that has all the files, and a branch for repo1 that has only the files in repo1. git-annex doesn't maintain such branches for you, but you can probably come up with a way to create such branches (`git annex find` will be useful when scripting up a solution).
+
+Or you can adopt the approach the git-annex assistant uses for archived files -- a archive/ directory, where files are moved when they're no longer wanted in the local system, so that their symlinks don't clutter up the view, while still being easily accessible when the time comes to pull something out of the archive.
+"""]]
diff --git a/doc/forum/add_only_binary_files__63__/comment_1_7ce3be5bafd62ce5ed78bcd9323039cc._comment b/doc/forum/add_only_binary_files__63__/comment_1_7ce3be5bafd62ce5ed78bcd9323039cc._comment
new file mode 100644
index 000000000..e53cb1f0f
--- /dev/null
+++ b/doc/forum/add_only_binary_files__63__/comment_1_7ce3be5bafd62ce5ed78bcd9323039cc._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 1"
+ date="2014-10-06T15:36:54Z"
+ content="""
+If you can configure `annex.largefiles` to match only binary files, then `git annex add` will respect it, and only add those files.
+
+For example, if you were working on a game written in C, and wanted to use git-annex only for the game art, but not the source code, you could configure it:
+
+    git config annex.largefiles 'largerthan=100kb and not (include=*.c or include=*.h)'
+
+This doesn't currently support looking at the file content to determine eg, its MIME type. That's been suggested as an added feature before.
+
+More simply, if you `git add` the non-binary files yourself first, `git annex add` will skip over those files and only add the other files.
+"""]]
diff --git a/doc/tips/googledriveannex/comment_7_3a645a0cd1e4c939b7a4b8a97a0e9b03._comment b/doc/tips/googledriveannex/comment_7_3a645a0cd1e4c939b7a4b8a97a0e9b03._comment
new file mode 100644
index 000000000..970a5e7b5
--- /dev/null
+++ b/doc/tips/googledriveannex/comment_7_3a645a0cd1e4c939b7a4b8a97a0e9b03._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.54"
+ subject="comment 7"
+ date="2014-10-06T15:23:59Z"
+ content="""
+Hugo, I didn't write this code, but it looks to me like you could work around the problem by changing line 207 of lib/CommonFunctions.py:
+
+<pre>
+diff --git a/lib/CommonFunctions.py b/lib/CommonFunctions.py
+index 050b93e..083f5d6 100644
+--- a/lib/CommonFunctions.py
++++ b/lib/CommonFunctions.py
+@@ -204,7 +204,7 @@ def fetchPage(params={}):
+         if get(\"progress\"):
+             data = False
+             tdata = \"\"
+-            totalsize = int(con.headers['content-length'])
++            totalsize = 0
+             chunksize = totalsize / 100
+             if chunksize < 4096:
+                 chunksize = 4096
+</pre>
+
+Probably the API used to return a content-length header, and no longer does, or doesn't do so reliably. It does not seem to be used for anything too important -- this change will break git-annex's progress display a little bit, perhaps.
+"""]]