response
This commit is contained in:
parent
15e35a80f5
commit
a69d87e984
1 changed files with 25 additions and 0 deletions
|
@ -0,0 +1,25 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 1"""
|
||||||
|
date="2019-09-16T17:27:12Z"
|
||||||
|
content="""
|
||||||
|
The documentation seems to clearly document the current behavior:
|
||||||
|
|
||||||
|
* `--json-error-messages`
|
||||||
|
|
||||||
|
Messages that would normally be output to standard error are included in
|
||||||
|
the json instead.
|
||||||
|
|
||||||
|
And changing the behavior could break something that relies on the current
|
||||||
|
behavior.
|
||||||
|
|
||||||
|
This was considered when the interface was designed, and there were
|
||||||
|
numerous good reasons to choose the current behavior.
|
||||||
|
[[See thread|todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output]].
|
||||||
|
|
||||||
|
(Another reason not mentioned there is, it's simply not possible to trap
|
||||||
|
every possible error message that git-annex could output in any circumstance.
|
||||||
|
If there's a segfault or a memory error, or libc crashes, or the program fails
|
||||||
|
to link. So any program parsing stderr for json would somehow have to deal
|
||||||
|
with this non-json that could be mixed up with it, which seems very hard.)
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue