| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Always include error-messages field, even if empty,
to make the json be self-documenting.
This was a design requirement for --json-error-messages.
This commit was supported by the NSF-funded DataLad project.
|
| |
|
|
|
|
|
|
|
|
|
| |
--json: When there are multiple lines of notes about a file, make the note
field multiline, rather than the old behavior of only including the last
line.
Using newlines in the note is perhaps not ideal, but upgrading it to an
array in this case would be an annoying inconsistency to need to deal with.
This commit was sponsored by Ole-Morten Duesund on Patreon.
|
| |
|
|
|
|
|
| |
It's left up to the special remote to detect when git-annex is new enough
to support the message; an old git-annex will blow up.
This commit was supported by the NSF-funded DataLad project.
|
| | |
|
| |
|
|
| |
known.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This gets rid of quite a lot of ugly hacks around json generation.
I doubt that any real-world json parsers can parse incomplete objects, so
while it's not as nice to need to wait for the complete object, especially
for commands like `git annex info` that take a while, it doesn't seem worth
the added complexity.
This also causes the order of fields within the json objects to be
reordered. Since any real json parser shouldn't care, the only possible
problem would be with ad-hoc parsers of the old json output.
|
| | |
|
| |
|
|
|
|
|
| |
Avoid threads emitting json at the same time and scrambling, which was
still possible even with the buffering, just less likely.
Converted json IO actions to JSONChunk data too.
|
| |
|
|
|
|
|
| |
the json output.
This doesn't work right when used with -J yet, and there is some really
ugly hand-crafting of part of the json output.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I've eyeballed all --json commands, and the only difference should be
that some fields are re-ordered.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Before, the json contained file:key; change that to key:
If a file and a key are given, inclue both file: and key:
|
| |
|
|
| |
"repositories containing these files", and "transfers in progress".
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* status: Fix --json mode (only the repository lists are currently
displayed)
* status: --fast is back
|
| | |
|
|
|
This includes a generic JSONStream library built on top of Text.JSON
(somewhat hackishly).
It would be possible to stream out a single json document describing
all actions, but it's probably better for consumers if they can expect
one json document per line, so I did it that way instead.
Output from external programs used for transferring files is not
currently hidden when outputting json, which probably makes it not very
useful there. This may be dealt with if there is demand for json
output for --get or --move to be parsable.
The version, status, and find subcommands have hand-crafted output and
don't do json. The whereis subcommand needs to be modified to produce
useful json.
|
Joey Hess
Joey Hess