mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2020-03-09 19:28:02 -04:00
commit 1fef36c243
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 39 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

9
doc/forum/Get_annex.dotfiles__61__true_behavior_without_persistent_configuration__63__/comment_11_1f46bcb05d7866af35779830ceb632e2._comment Normal file
View file

@ -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?
"""]]

30
doc/forum/Preferred_contents_based_on_presence_in_repo/comment_3_6aaf8226051e9dd104da206b032cfe5a._comment Normal file
View file

@ -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.
```
"""]]