Always run Git.Config.store, so when the git config gets reloaded,
the override gets re-added to it, and changeGitRepo then calls extractGitConfig
on it and sees the annex.* settings from the override.
Remove any prior occurance of -c v and add it to the end. This way,
-c foo=1 -c foo=2 -c foo=1 will pass -c foo=1 to git, rather than -c foo=2
Note that, if git had some multiline config that got built up by
multiple -c's, this would not work still. But it never worked because
before the bug got fixed in the first place, the -c value was repeated
many times, so the multivalue thing would have been wrong. I don't think
-c can be used with multiline configs anyway, though git-config does
talk about them?
This reverts commit e930237f61.
Unbelievably, that worked, somehow the preprocessed file had gotten
cached from the wrong version. Windows has found a new way to amaze me in
its horribleness.
build is failing on commit d409f92318
but the error message quotes a version of Utility/Process/Transcript.hs
before a fix yesterday. All I can think is stack may have cached the old
version, perhaps after cpp?
This adds a dep on hashable, but it's a free dependency, since
unordered-containers already pulled it in.
Using unordered-containers for the set seems to make sense, since it
hashes and bloom filter hashes too. (Though different hashes.)
I dunno, never quite know if I should use unordered-containers or containers.
In stack-lts-12.14.yaml, there were dep issues using the new libraries,
which may not be resolvable with those old versions. Didn't check, just
disabled using the libraries there, which will hold us for a couple
years.
(It would probably be easy enough to relax some of the dep versions in
http-client-restricted and git-lfs to the older versions.)
