comment

1 files changed, 23 insertions, 0 deletions

diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment
new file mode 100644
index 000000000..eeaafa9ed
--- /dev/null
+++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment
@@ -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.
+"""]]