| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use nextRandom to generate the random UUID, rather than using randomIO.
This gets fixes for the following two bugs in the uuid library.
However, this did not impact git-annex much, so a hard depedency has
not been added on uuid-1.3.12.
https://github.com/aslatter/uuid/issues/15
"v4 UUIDs are not that random"
This doesn't greatly affect git-annex, because even with only
2^64 possible UUIDs, the chance that two git-annex repositories
that are clones of the same git repo get the same UUID is miniscule.
And, git-annex generates only one UUID per run, so preducting
subsequent UUIDs is not a problem.
https://github.com/aslatter/uuid/issues/16
"Remove Random instance for UUID, or mark it as deprecated"
git-annex was using that instance; let's stop before it gets
deprecated or removed.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I've eyeballed all --json commands, and the only difference should be
that some fields are re-ordered.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
metadata --json output format has changed, adding a inner json object
named "fields" which contains only the fields and their values.
This should be easier to parse than the old format, which mixed up
metadata fields with other keys in the json object.
Any consumers of the old format will need to be updated.
This adds a dependency on unordered-containers for parsing MetaData
from JSON, but it's a free dependency; aeson pulls in that library.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Keeping Text.JSON use for now, because it seems a better fit for most of
the commands, which don't use very structured JSON objects, but just output
whatever fields suites them. But this lets Aeson be used when a more
structured data type is available to serialize to JSON.
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
| |
closes https://github.com/joeyh/git-annex/pull/55
* git-annex.cabal: Temporarily limit to http-conduit <2.2.0
since aws 0.14.0 is not compatible with the newer version.
* git-annex.cabal: Temporarily limit to persistent <2.5
since esqueleto 2.4.3 is not compatible with the newer version.
|
|
|
|
|
|
|
|
|
|
|
|
| |
aws 0.14.0 is incompatible with http-conduit 2.2.0
https://github.com/aristidb/aws/issues/206
esqueleto 2.4.3 is incompatible with persistent 2.5
https://github.com/prowdsponsor/esqueleto/issues/137
https://github.com/prowdsponsor/esqueleto/pull/141
https://github.com/prowdsponsor/esqueleto/pull/139
Solver needs these hints when building git-annex with +S3 and +Webapp.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Using the many combinator resulted in Just (WantBranchKeys []) which
bypassed the defualt used for Nothing.
|
|
|
|
|
|
|
|
| |
Show branch:file that is being operated on.
I had to make ActionItem a type and not a type class because
withKeyOptions' passed two different types of values when using the type
class, and I could not get the type checker to accept that.
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and
whereis commands. This option makes git-annex operate on files that are
included in a specified branch (or other treeish).
The names of the files from the branch that are being operated on are not
displayed yet; only the keys. Displaying the filenames will need changes
to every affected command.
Also, note that --branch can be specified repeatedly. This is not really
documented, but seemed worth supporting, especially since we may later want
the ability to operate on all branches matching a refspec. However, when
operating on two branches that contain the same key, that key will be
operated on twice.
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
https://github.com/commercialhaskell/stack/issues/2371
Also don't recommend using cabal unpack to get the source, since the git
clone has a more extensive source tree.
|
| |
|
| |
|
|
|
|
|
| |
It's a mvar lookup either way, but I think this way will be slightly more
efficient. And it reduces the number of places where it's checked to 1.
|
| |
|
| |
|
|
|
|
| |
supposed to use that database.
|
|
|
|
| |
hostnames. This allows IPv6 addresses to be used on filesystems not supporting : in filenames.
|
| |
|