mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2018-02-08 13:12:39 -04:00
parent e8c5db3624
commit 68321be178
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 23 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2018-02-08T16:59:16Z"
content="""
Is the benefit of doing this being able to correlate the error message with
the filename whose processing caused the error?
For that benefit to be realized, the error message would have to be included
in the same json object with the file being processed. If a separate json
object were emitted containing only the error message it would not be clear
what file it was related to (especially when git-annex is running
concurrent jobs), and so that does not seem any better than
output to stderr.
Looks like implementation would just involve making outputError
check if there is a jsonBuffer, and add the error message to it,
probably using an array since there could be multiple warning messages.
I kind of feel like they should still go to stderr in addition to any json
output, because any existing json consumers may rely on the current stderr
behavior to let the user know what went wrong.
"""]]