In order to remove some hackishness in git annex sync --content
, I
finally fixed a bad design decision I made back at the very beginning
(before I really knew haskell) when I built the command seek code, which
had led to a kind of inversion of control. This took most of a night, but
it made a lot of code in git-annex clearer, and it makes the command
seeking code much more flexible in what it can do. Some of the oldest, and
worst code in git-annex was removed in the process.
Also, I've been reworking the numcopies configuration, to allow for a
?preferred content numcopies check. That will let the assistant,
as well as git annex sync --content
proactively make copies when
needed in order to satisfy numcopies.
As part of this, git config annex.numcopies
is deprecated, and there's a
new git annex numcopies N
command that sets the numcopies value that will
be used by any clone of a repository.
I got the preferred content checking of numcopies working too. However, I am unsure if checking for per-file .gitattributes annex.numcopies settings will make preferred content expressions be, so I have left that out for now.
Today's work was sponsored by Josh Taylor.
Some more details on
would be appreciated.
Richard
I don't plan to remove .git/config annex.numcopies support. It is 5 lines of code.
A fundamental problem with the .git/config annex.numcopies setting is that it can be inconsistently set between repositories. Therefore, there is no worse potential with interoperability if you use differing versions of git-annex that support and do not support the new global numcopies setting. If this was a concern though, you can use .gitattributes to set annex.numcopies for *, which all recent versions of git-annex support.
The old git/config annex.numcopies setting is overridden as soon as you use
git annex numcopies
. In turngit annex numcopies
is overridden by any relevant .gitattributes annex.numcopies setting. This is documented on the man page.