Added a comment
This commit is contained in:
parent
2fa5ef6a36
commit
a33b40876d
1 changed files with 12 additions and 0 deletions
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue