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

Added a comment

Browse source
This commit is contained in:
yarikoptic 2022-02-28 18:48:51 +00:00 • committed by admin
parent 2fa5ef6a36
commit a33b40876d
1 changed files with 12 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

12
doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_1_672457817d5dca898f5aefbe97da9b23._comment Normal file
View file

@ -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.
"""]]