Added a comment

diff --git a/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_1_672457817d5dca898f5aefbe97da9b23._comment b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_1_672457817d5dca898f5aefbe97da9b23._comment
new file mode 100644 (file)
index 0000000..d37afaf
--- /dev/null
+++ b/doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_1_672457817d5dca898f5aefbe97da9b23._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2022-02-28T18:48:50Z"
+ content="""
+> This does risk breaking things that parse the existing JSON and fall over on the new record, but I think git-annex should be free to add new records and fields to its JSON output in general, and it has probably at least added new fields before. 
+
+Although sounds logical, FWIW, not sure if DataLad would be robust to such an assumption since I don't think it was exercised before and indeed all returned records were typically associated with some particular `\"path\"` so our code might rely on that.  Also it makes it a bit unclear on what datalad code should do with \"unrecognized\" outputs -- are they sign of a problem, or could be safely ignored?
+
+Ideally, IMHO and IIRC, DataLad should not concern itself with exit codes of `git` commands which `git-annex` ran -- it should be up to `git-annex` to decide on what any particular underlying `git` invocation supposed to do etc.  I guess only in the cases of some faulty, unknown to git-annex how to handle, behavior where git-annex itself reports an error, might be worth including details on underlying failed `git` invocation in the output, so datalad also could channel it to the user. 
+"""]]