From 68321be17828e235a3a79baac7902eca799f6bf7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 8 Feb 2018 13:12:39 -0400 Subject: [PATCH] comment --- ..._f02e43b68c219b2d7d65ea868fac125f._comment | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_1_f02e43b68c219b2d7d65ea868fac125f._comment 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 0000000000..eeaafa9ed1 --- /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. +"""]]