diff --git a/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option.mdwn b/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option.mdwn
new file mode 100644
index 0000000000..fa23108ea6
--- /dev/null
+++ b/doc/bugs/git-annex-shell_doesn__39__t_honour_Rsync__39__s_bwlimit_option.mdwn
@@ -0,0 +1,35 @@
+<h4>What steps will reproduce the problem?</h4>
+
+On <tt>host1.example.tld</tt>:
+<pre><code>    git init /tmp/annex
+    cd /tmp/annex
+    git annex init
+    git config annex.rsync-options '--bwlimit=100'
+    dd if=/dev/urandom of=bigfile bs=1024 count=102400
+    git annex add bigfile
+    git commit -am bigfile
+</code></pre>
+
+On <tt>host2.example.tld</tt>:
+<pre><code>    git clone ssh://host1.example.tld/tmp/annex /tmp/annex
+    cd /tmp/annex
+    git annex init
+    git config annex.rsync-options '--bwlimit=100'
+    git annex get --from=origin bigfile
+</code></pre>
+
+<h4>What is the expected output? What do you see instead?</h4>
+<tt>bigfile</tt> is retrieved full speed, despite the <tt>bwlimit</tt> option. In fact on the origin <tt>host1.example.tld</tt>, <tt>ps x | grep rsync</tt> shows:
+<pre><code>
+    21386 ?        Ssl    0:00 git-annex-shell sendkey /tmp/annex SHA256E-s104857600--3e87b769b88db67c56f8c8a0245203a1c22cdb027f0a1230dac8309b1a9fded0 --uuid 7002cb3d-2205-4
+f8d-892b-5c35c693d76c -- remoteuuid=67263f47-7a5f-4a75-937b-7cffafa85f56 direct= associatedfile=bigfile -- dummy rsync --server --sender -ve.Lsf --bwlimit=100 --inplace .
+    21390 ?        S      0:01 rsync --server -t --inplace -e.Lsf . --sender /tmp/annex/.git/annex/objects/jX/3W/SHA256E-s104857600--3e87b769b88db67c56f8c8a0245203a1c22cdb02
+7f0a1230dac8309b1a9fded0/SHA256E-s104857600--3e87b769b88db67c56f8c8a0245203a1c22cdb027f0a1230dac8309b1a9fded0
+</code></pre>
+
+On the first line the option is indeed there, but it's somehow not forwarded to the actual rsync command. (On the client <tt>host2.example.tld</tt> the option shows up, but the sender's bandwidth seems to take precedence.)
+
+<h4>What version of git-annex are you using? On what operating system?</h4>
+
+git-annex 4.20130227, on Debian GNU/Linux (sid, i386).
+
diff --git a/doc/forum/Difference_between_copy__44___move_and_get__63__/comment_1_26ee8192af3a62178c1ccf17c6da5ca5._comment b/doc/forum/Difference_between_copy__44___move_and_get__63__/comment_1_26ee8192af3a62178c1ccf17c6da5ca5._comment
new file mode 100644
index 0000000000..fb1aed5da1
--- /dev/null
+++ b/doc/forum/Difference_between_copy__44___move_and_get__63__/comment_1_26ee8192af3a62178c1ccf17c6da5ca5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-09T02:00:11Z"
+ content="""
+There is no particular reason to use any of copy, move, or get. Use which ever command makes sense at the time.
+
+The problem you're encoutering is that you have an old, and broken version of git-annex installed. Upgrade and the error message will go away and both get and copy, in your example, will work.
+"""]]
diff --git a/doc/forum/wishlist:_GnuPG_options/comment_1_6662e8a71ce20acc62147ef41ecffa50._comment b/doc/forum/wishlist:_GnuPG_options/comment_1_6662e8a71ce20acc62147ef41ecffa50._comment
new file mode 100644
index 0000000000..b756eccade
--- /dev/null
+++ b/doc/forum/wishlist:_GnuPG_options/comment_1_6662e8a71ce20acc62147ef41ecffa50._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-09T01:54:30Z"
+ content="""
+I'd be happy to apply a patch implementing annex.gnupg-options and/or per-remote remote.annex-gnupg-options, and I don't think it would be very hard to do.
+
+The gitattributes thing would be harder to do efficiently, and seems overkill.
+
+
+"""]]