From 8dc9b5d6269e89466b87db0bcf75893ef68e2c0a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 16 Feb 2018 13:28:13 -0400 Subject: comment --- .../comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment diff --git a/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment new file mode 100644 index 000000000..d3872b23e --- /dev/null +++ b/doc/todo/include_msg_with_possible_reason_why_command___40__e.g._add__41___failed_into_--json_output/comment_3_2d41d67dcb6e700b1ecda3106e444a5e._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2018-02-16T16:50:27Z" + content=""" +A problem with this idea is that error messages are relatively uncommon, +and if they're hidden away in an extra field of an existing json message, +it would be easy for the consumer to forget to handle that uncommon case. + +Note that git-annex currently doesn't document the actual json structure it +uses, which is more or less ok because any given git-annex subcommand will +always output the same json structure (except some note fields that +only sometimes appear, whose data is targeted at humans). +It's self-documenting. Using json for errors breaks that pattern. +"""]] -- cgit v1.2.3