Where before the "name" of a key and a backend was a string, this makes
it a concrete data type.
This is groundwork for allowing some varieties of keys to be disabled
in file2key, so git-annex won't use them at all.
Benchmarks ran in my big repo:
old git-annex info:
real 0m3.338s
user 0m3.124s
sys 0m0.244s
new git-annex info:
real 0m3.216s
user 0m3.024s
sys 0m0.220s
new git-annex find:
real 0m7.138s
user 0m6.924s
sys 0m0.252s
old git-annex find:
real 0m7.433s
user 0m7.240s
sys 0m0.232s
Surprising result; I'd have expected it to be slower since it now parses
all the key varieties. But, the parser is very simple and perhaps
sharing KeyVarieties uses less memory or something like that.
This commit was supported by the NSF-funded DataLad project.
Even if annex.backends does not include a backend, that does not prevent
git-annex commands from acting on a file using the missing backend.
(There's really no reason at all for annex.backends to be a list.)
Otherwise, make reconfigures every time and then rebuilds all files.
I went too far in 3af9f5ed1a. All that's
needed is to make the configure target not use Build/SysConfig.hs as the
target name, so make won't delete that file after a failed build.
This commit was supported by the NSF-funded DataLad project
I am not happy that I had to put backend-specific code in file2key. But
it would be very difficult to avoid this layering violation.
Most of the time, when parsing a Key from a symlink target, git-annex
never looks up its Backend at all, so adding this check to a method of
the Backend object would not work.
The Key could be made to contain the appropriate
Backend, but since Backend is parameterized on an "a" that is fixed to
the Annex monad later, that would need Key to change to "Key a".
The only way to clean this up that I can see would be to have the Key
contain a LowlevelBackend, and put the validation in LowlevelBackend.
Perhaps later, but that would be an extensive change, so let's not do
it in this commit which may want to cherry-pick to backports.
This commit was sponsored by Ethan Aubin.
This was noticed because it broke the datalad test suite, which pushed
to the remote and then fetched to check if it had received the expected
branches. Auto-init caused the git-annex branch on the remote to
diverge, breaking that test.
https://github.com/datalad/datalad/issues/1319#issuecomment-281649518
The auto-init still happens, it's staged in the journal, and will be
commited by some later git-annex command when it runs. Which is fine,
it's the same as that later command doing the auto-init.
This commit was supported by the NSF-funded DataLad project
The problem with that target was, if a target like git-annex that
depended on it failed for some reason, make would delete
Build/SysConfig.hs, since it knows it's an intermediate file. But, since
stack only builds that file once, that caused all subsequent make git-annex
builds to fail.
Also, this avoids a double stack build when building with stack. Since
stack has no configure stage, and the Build/SysConfig.hs target was
about running the configure stage, the only way to only build once is to
combine the targets like this.
This should work better on the autobuilders that build with stack.
This commit was sponsored by NSF-funded DataLad project
* Run curl with -S, so HTTP errors are displayed, even when
it's otherwise silent.
* When downloading in --json or --quiet mode, use curl in preference
to wget, since curl is able to display only errors to stderr, unlike
wget.
This does mean that downloadQuiet is only silent on stdout, not necessarily
on stderr, which affects a couple other calls of it. For example,
downloading the .git/config of a http remote may show an error message now,
perhaps with slightly suboptimal formatting due to other output.
This adds one extra line of output when a download is successful,
after the progress bar. I don't much like that, but wget does not provide a
way to show HTTP errors without it.
I've seen this thing, whatever it is, mentioned in spam links before,
so even if it's valid for some OS (probably not the one being asked
about), it's verboten here.
