diff --git a/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_11_1f46bcb05d7866af35779830ceb632e2._comment b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_11_1f46bcb05d7866af35779830ceb632e2._comment
new file mode 100644
index 0000000000..b8a934e587
--- /dev/null
+++ b/doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_11_1f46bcb05d7866af35779830ceb632e2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="sam.nastase@2b4a9b3e5094dab41e0a4de0b808a2697a3e9860"
+ nickname="sam.nastase"
+ avatar="http://cdn.libravatar.org/avatar/55c74b521bcb7322069f35bf655f81e0"
+ subject="comment 11"
+ date="2020-03-09T22:43:56Z"
+ content="""
+I'm on an institutional server and don't have admin privileges, so I'm using the existing conda (v4.7.5) installation and installing datalad with `conda install -c conda-forge datalad`. On a second try, can confirm that `git` is not listed among the conda `NEW packages that will be INSTALLED`, although it does get `git-annex conda-forge/linux-64::git-annex-8.20200226-nodep_h1234567_1` (as well as `gitdb` and `gitpython`). Conda env still points to the external git installation. Running the conda version of `datalad save` gives me the `Invalid option `--include-dotfiles'` error, so I install from GitHub with `pip install git+https://github.com/datalad/datalad.git`. However, this doesn't seem to change anything (I think this is why I ended up conda uninstalling datalad previouosly). Is there away to ensure the version installed from GitHub via pip takes precedence?
+"""]]
diff --git a/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_3_6aaf8226051e9dd104da206b032cfe5a._comment b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_3_6aaf8226051e9dd104da206b032cfe5a._comment
new file mode 100644
index 0000000000..8e90e2ebd9
--- /dev/null
+++ b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_3_6aaf8226051e9dd104da206b032cfe5a._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="re: rationale"
+ date="2020-03-09T22:17:51Z"
+ content="""
+> Is there a rationale for not having the option for preferred contents?
+
+Hmm, I wouldn't be able to answer this myself, but digging around a
+bit it looks like there used to be an `in=` option.  Here's the
+rationale given in that commit:
+
+```
+CommitDate: Fri Oct 19 16:09:21 2012 -0400
+40aab719dfe9c3bd240656c1ff387cad0ba8d96d
+
+Replace \"in=\" with \"present\" in preferred content expressions
+
+in= was problimatic in two ways. First, it referred to a remote by name,
+but preferred content expressions can be evaluated elsewhere, where that
+remote doesn't exist, or a different remote has the same name. This name
+lookup code could error out at runtime. Secondly, in= seemed pretty useless.
+in=here did not cause content to be gotten, but it did let present content
+be dropped.
+
+present is more useful, although \"not present\" is unstable and should be
+avoided.
+```
+
+"""]]