dial back addition, but keep it
It's a semi-common point of confusion that numcopies is not something these commands go out and copy files around specifically to satisfy, without further configuration in preferred content. So this is a good addition, but it also seemed too long and too specific to the user's particular situation.
This commit is contained in:
parent
668db84e51
commit
a237f98a70
1 changed files with 3 additions and 8 deletions
|
@ -16,14 +16,9 @@ and pushing of git repositories, and without changing the trees that are
|
||||||
imported to or exported from special remotes.
|
imported to or exported from special remotes.
|
||||||
|
|
||||||
Note that it (like [[git-annex-sync]] or [[git-annex-assist]]) does not work
|
Note that it (like [[git-annex-sync]] or [[git-annex-assist]]) does not work
|
||||||
specifically towards satisfying the [[git-annex-numcopies]] setting and it will
|
specifically towards satisfying the [[git-annex-numcopies]] setting,
|
||||||
not violate the local preferred content expression in order to move files
|
unless the preferred content setting of the local repository is written to
|
||||||
between remotes that are not present locally. To allow for files to be present
|
do so by using eg `approxlackingcopies=1`.
|
||||||
locally for such a movement between remotes, consider adding `or
|
|
||||||
approxlackingcopies=1` to your local [[preferred_content]] expression (and
|
|
||||||
maybe increasing [[git-annex-numcopies]] accordingly) so that files may pass
|
|
||||||
through your local repo temporarily. Otherwise, `git annex satisfy` does not
|
|
||||||
see a pathway for files to pass between other remotes.
|
|
||||||
|
|
||||||
# OPTIONS
|
# OPTIONS
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue