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

8 files changed, 147 insertions, 2 deletions

diff --git a/doc/bugs/Complete_failure_trying_to_unannex_a_large_annex/comment_1_1c202695ab7fe62cdc8770e1fb428d0c._comment b/doc/bugs/Complete_failure_trying_to_unannex_a_large_annex/comment_1_1c202695ab7fe62cdc8770e1fb428d0c._comment
new file mode 100644
index 000000000..82acacd75
--- /dev/null
+++ b/doc/bugs/Complete_failure_trying_to_unannex_a_large_annex/comment_1_1c202695ab7fe62cdc8770e1fb428d0c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-08T19:02:54Z"
+ content="""
+You seem to have a corrupt .git/index file, or .git/annex/index, or maybe a whole corrupt git repository. I'm not sure. I'd start by running `git fsck`, and if that's ok, remove `.git/annex/index` and `.git/annex/index.lck`. git-annex will recover from that automatically. If that still doesn't help, you might need to delete .git/index and do some reset to get it back.
+
+I don't see much evidence of an actual bug here, just bad data that is somehow on disk.
+"""]]
diff --git a/doc/bugs/Rsync_encrypted_remote_asks_for_ssh_key_password_for_each_file/comment_1_fd95e0bb61e80a72b4ac1304ef6c2e77._comment b/doc/bugs/Rsync_encrypted_remote_asks_for_ssh_key_password_for_each_file/comment_1_fd95e0bb61e80a72b4ac1304ef6c2e77._comment
new file mode 100644
index 000000000..5f55f356b
--- /dev/null
+++ b/doc/bugs/Rsync_encrypted_remote_asks_for_ssh_key_password_for_each_file/comment_1_fd95e0bb61e80a72b4ac1304ef6c2e77._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-08T18:59:27Z"
+ content="""
+git-annex does not use ssh connection caching for rsync special remotes, and so if you've configured ssh such that it needs to prompt for a password when making a connection, you'll be prompted twice for each file when using `git annex copy`: Once when it checks if the file is present, once when it rsyncs it. (One of those can be avoided by passing --fast)
+
+I don't see where a third password prompt can come from, other than gpg. But that would only prompt once per git-annex command, since git-annex caches the remote's encryption key.
+
+Of course, you can use a ssh-agent to avoid repeated ssh password prompts.
+
+----
+
+There's certainly a valid wishlist todo item that the rsync special remote should support ssh connection caching. It could be implemented using rsync -e. Although it would need to parse all valid rsync urls to determine which use ssh and which not, and what the user and hostname are.
+"""]]
diff --git a/doc/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/comment_8_78e6164ef67a9560a3a9ead1f7a72473._comment b/doc/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/comment_8_78e6164ef67a9560a3a9ead1f7a72473._comment
new file mode 100644
index 000000000..c49cbbeef
--- /dev/null
+++ b/doc/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/comment_8_78e6164ef67a9560a3a9ead1f7a72473._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="173.162.44.162"
+ subject="comment 8"
+ date="2013-03-08T14:46:55Z"
+ content="""
+I've not seen this kind of strange behavior happen again so far.
+
+But I have got another example of a file which I added to git-annex via the assistant not having its symlink added to git.  Again, the content of the file is in git-annex and was even correctly transferred to a couple of remotes, but the symlink is still unstaged.
+
+I tried restarting the assistant to see if that would fix it but that didn't change anything.
+
+I imagine the symlink will be fixed during a daily scan, tomorrow maybe?  Is it problematic for the symlink not to be checked into git for a day?  Is this worth a bug report or is this really harmless behavior?
+
+"""]]
diff --git a/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn b/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn
new file mode 100644
index 000000000..f3370fcb6
--- /dev/null
+++ b/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn
@@ -0,0 +1,55 @@
+**What steps will reproduce the problem?**
+
+I did a basic git annex setup with two repositories talking to each other.  They are on the same macine, but I identified them via the hostname, because I intend to set up my production systems on two machines.  Since I am new to annex, I'll reproduce the full sequence of commands to create the repos and sync them.  *I* noticed the trouble at the last step, when `git annex get` failed.
+
+Here is the full sequence of commands:
+
+    >>> cd /scr/wandschn/hackNtest/distributed/nyc/STU_files
+    >>> git init
+    >>> git annex init nyc
+    >>> cd /scr/wandschn/hackNtest/distributed/pdx
+
+    >>> git clone xerxes:/scr/wandschn/hackNtest/distributed/nyc/STU_files
+    >>> git annex init pdx
+    >>> git remote add nyc xerxes:/scr/wandschn/hackNtest/distributed/nyc/STU_files
+
+    >>> cd /scr/wandschn/hackNtest/distributed/nyc/STU_files
+    >>> git remote add pdx xerxes:/scr/wandschn/hackNtest/distributed/pdx/STU_files
+
+    >>> mkdir shared
+    >>> cp ../../../files/shared/* shared/.
+    >>> git annex add shared
+    >>> git commit -a -m "initial add of shared files"
+
+    >>> cd /scr/wandschn/hackNtest/distributed/pdx/STU_files
+    >>> git fetch nyc
+    >>> git merge nyc/master
+    >>> ls shared/135.mae
+    shared/135.mae
+    >>> git annex whereis shared/135.mae
+    whereis shared/135.mae (1 copy)
+            6f0368db-f1b1-4192-9200-3575c16c2ef1 -- origin (nyc)
+    ok
+    >>> git annex get shared/135.mae
+    fatal: Could not switch to '../.git/annex/objects/KV/5f/SHA256-s1499628--4a7e2ba13096ee2d1a6b3c3b314efae623516d200c09d35ff0f695395b6ad47a': No such file or directory
+
+    git-annex: <file descriptor: 4>: hGetLine: end of file
+    failed
+    git-annex: get: 1 failed
+
+**What is the expected output? What do you see instead?**
+
+I expected the file shared/135.mae to be copied from the remote repo to the local repo.  Instead, this command failed, and said that there was a missing file.  This file path is the one that the broken link points to, and it exists on the remote repo.
+
+**What version of git-annex are you using? On what operating system?**
+
+git version 1.7.9.6
+
+git-annex 3.20120523
+
+CentOS 6.3 (kernel 2.6.32)
+
+64bit Xeon processor
+
+
+**Please provide any additional information below.**
diff --git a/doc/bugs/git-annex_doesn__39__t_list_files_containing_ISO8859-15_characters.mdwn b/doc/bugs/git-annex_doesn__39__t_list_files_containing_ISO8859-15_characters.mdwn
new file mode 100644
index 000000000..4ec042840
--- /dev/null
+++ b/doc/bugs/git-annex_doesn__39__t_list_files_containing_ISO8859-15_characters.mdwn
@@ -0,0 +1,35 @@
+<h4>What steps will reproduce the problem?</h4>
+<pre><code>    git init /tmp/test
+    cd /tmp/test
+    git annex init
+    touch òó ō
+    git annex add òó ō
+    git annex find --include='*'
+</code></pre>
+
+<h4>What is the expected output? What do you see instead?</h4>
+Only <tt>ō</tt> is listed. Files containing ISO8859-15 characters that are not in ASCII-7, such as <tt>òó</tt>, are not listed by
+<code>git annex find --include='*'</code>. On the other hand, <code>git annex find --in=here</code> lists both.
+
+<h4>What version of git-annex are you using? On what operating system?</h4>
+git-annex 4.20130227, on Debian GNU/Linux (sid, i386).
+
+<h4>Please provide any additional information below.</h4>
+<pre><code>    ~$ locale
+    LANG=en_US.UTF-8
+    LANGUAGE=en
+    LC_CTYPE="en_US.UTF-8"
+    LC_NUMERIC=C
+    LC_TIME=en_DK.UTF-8
+    LC_COLLATE="en_US.UTF-8"
+    LC_MONETARY="en_US.UTF-8"
+    LC_MESSAGES="en_US.UTF-8"
+    LC_PAPER=sv_SE.UTF-8
+    LC_NAME=sv_SE.UTF-8
+    LC_ADDRESS=sv_SE.UTF-8
+    LC_TELEPHONE=sv_SE.UTF-8
+    LC_MEASUREMENT=sv_SE.UTF-8
+    LC_IDENTIFICATION="en_US.UTF-8"
+    LC_ALL=
+</code></pre>
+
diff --git a/doc/forum/wishlist:_GnuPG_options.mdwn b/doc/forum/wishlist:_GnuPG_options.mdwn
new file mode 100644
index 000000000..4d8bfb401
--- /dev/null
+++ b/doc/forum/wishlist:_GnuPG_options.mdwn
@@ -0,0 +1,14 @@
+[Maybe I should have extented [[this thread|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/]], but I thought I'd make my own since it's perhaps too old.]
+
+I second Justin and [[his idea|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/#comment-e120f8ede0d4cffce17cbf84564211c1]] of having per-remote GnuPG options. I'd even go one step further, and propose the option in the <tt>.gitattributes</tt> file. Indeed by default GnuPG compresses the data before encryption, which doesn't make a lot of sense for git-annex (in my use-case at least); My work-around to save this waste of CPU cycles was to customize my <tt>gpg.conf</tt>, but it's somewhat dirty since I do want to use compression in general.
+
+Here is how I envision the <tt>.git/config</tt>:
+<pre>    <code>[annex]
+        gnupg-options = --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo none
+</code></pre>
+
+And compression could be enabled on say, text files, with a suitable wildcard in the <tt>.gitattributes</tt> file.
+<pre>    <code>*.txt annex.gnupg-options="--s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo zlib"
+</code></pre>
+
+This is something I could probably hack on if you think it'd be a worthwhile option ;-)
diff --git a/doc/index.mdwn b/doc/index.mdwn
index fadc27e6a..56cd9811a 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -62,7 +62,7 @@ files with git.
 <table>
 <tr>
 <td width="50%" valign="top">
-[[!inline raw=yes pages="videos/Fosdem2012"]]
+[[!inline raw=yes pages="videos/FOSDEM2012"]]
 </td>
 <td width="50%" valign="top">
 [[!inline raw=yes pages="videos/LCA2013"]]
diff --git a/doc/videos/Fosdem2012.mdwn b/doc/videos/FOSDEM2012.mdwn
index 27a8e9ec3..c1a381939 100644
--- a/doc/videos/Fosdem2012.mdwn
+++ b/doc/videos/FOSDEM2012.mdwn
@@ -1,4 +1,4 @@
 <video controls
 src="http://video.fosdem.org/2012/lightningtalks/git_annex___manage_files_with_git,_without_checking_their_contents_into_git.webm" width="100%"></video><br>
 A <a href="http://video.fosdem.org/2012/lightningtalks/git_annex___manage_files_with_git,_without_checking_their_contents_into_git.webm">15 minute introduction to git-annex</a>,
-presented by Richard Hartmann at Fosdem 2012.
+presented by Richard Hartmann at FOSDEM 2012.