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

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2023-04-25 17:08:52 -04:00
commit 7c514d717b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 47 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

10
doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_5_7501eed2e6cb732966277ef2f1ff28e9._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 5"
date="2023-04-25T18:31:20Z"
content="""
Yes -- having some UNIQUEIDs for errors might be quite great!
As for specific field to identify what that error applicable to: the other changed behavior which broke our code/tests was the change to behavior of `annex info` to no longer list unknown to annex path in `\"file\"` and rather list it in `\"input\"` for which the [PR](https://github.com/datalad/datalad/pull/7372/files) was cooked up already. So may be here it also just should be `\"input\"` field if `annex` desires to not make claims on either it is a `\"file\"` or may be some \"pathspec\" (well -- in DataLad nobody was brave enough to open that -- path-vs-pathspec -- pandora box [see issues/6933](https://github.com/datalad/datalad/issues/6933))?
"""]]

37
doc/todo/api_for_telling_when_nonexistant_or_non_git_files_passed/comment_6_7a5b3d2694a48e4e44436f6bf7ed6642._comment Normal file
View file

@ -0,0 +1,37 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 6"
date="2023-04-25T18:45:58Z"
content="""
Just for completeness -- do we really need a new type of record for this? In immediate use case which is [in the heart of the path escaping change discussion](https://git-annex.branchable.com/bugs/started_to_escape_characters_in_the_output/) let's consider other commands. E.g. `addurl` already reports `--json-errors` just fine in a similar case
```shell
❯ git annex addurl --json --json-error-messages '\e[31mfo\o\e[0m'
{\"command\":\"addurl\",\"error-messages\":[\"git-annex: bad url \\e[31mfo\\o\\e[0m\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false}
addurl: 1 failed
```
so why just not to make `add`'s
```shell
❯ git annex add --json --json-error-messages '\e[31mfo\o\e[0m'
git-annex: \e[31mfo\o\e[0m not found
add: 1 failed
```
into
```shell
{\"command\":\"add\",\"error-messages\":[\"git-annex: \\e[31mfo\\o\\e[0m not found\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false}
add: 1 failed
```
or if you want to expand with unambigous ID:
```
{\"command\":\"add\",\"error-messages\":[\"git-annex: \\e[31mfo\\o\\e[0m not found\"],\"file\":null,\"input\":[\"\\e[31mfo\\o\\e[0m\"],\"success\":false, \"errorid\": \"NOT_FOUND\"}
add: 1 failed
```
or alike without requiring some new CLI option?
"""]]