avoid ugly error message
Http remotes that do expose a git config file, but are not initialized resulted in an ugly and unncessary error message, now sqelched. When git-annex-shell configlist is run w/o the autoinit field, it may not generate a uuid for the repository. So in that case, it's not unexpected for the config it does list to not include a UUID, and dumping out the config in a warning message is not needed. If configlist is asked to autoinit and we don't get back a config with a UUID in it, that suggests some problem, and what we got back may not be a config at all but some diagnostic message, so it does make sense to output it then.
This commit is contained in:
parent
8cda10777a
commit
d227093002
4 changed files with 49 additions and 4 deletions
|
@ -143,4 +143,6 @@ git annex 7.20190819+git2-g908476a9b-1~ndall+1 and the same with bleeding edge 7
|
|||
[[!meta author=yoh]]
|
||||
[[!tag projects/dandi]]
|
||||
|
||||
> [[fixed|done]] what I consider to be the core issue in this bug report.
|
||||
> --[[Joey]]
|
||||
|
||||
|
|
|
@ -0,0 +1,41 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2020-01-22T15:11:05Z"
|
||||
content="""
|
||||
I've said this before, but I'll say it one more time: --json-error-messages
|
||||
is not a guarantee that every possible error message that may be output by
|
||||
git-annex in some exceptional circumstance will be formatted as json.
|
||||
|
||||
In this case, while I happened to make it be captured in an unrelated
|
||||
change, there's actually no benefit to it being captured. If it were no
|
||||
longer captured tomorrow, I would not consider that a bug. This error
|
||||
message is not specific to a particular file in the repository, so if
|
||||
git-annex get outputs it, it doesn't help for the error message to be
|
||||
wrapped up in json. The actual purpose of --json-error messages is being
|
||||
able to correlate a failure to eg, get a particular file with an error
|
||||
message related to that action. Not in avoiding all possible stderr.
|
||||
|
||||
----
|
||||
|
||||
The extra newlines output to stdout are there because the `warning` action
|
||||
does not know if something may have been output to stdout earlier without a
|
||||
terminating newline, and it wants to avoid an ugly interleave of stdout and
|
||||
stderr. While state could be maintained to keep track of that, the end
|
||||
result would be git-annex would become some milliseconds slower, and it
|
||||
does not seem worth the complexity or minor speed hit to cater to the case
|
||||
where stderr is /dev/nulled. Note that this doesn't happen when using
|
||||
--json. Also, IIRC it's avoided when using concurrent output, which does
|
||||
pay the time/complexity overhead already to keep track of the state of the
|
||||
display to that extent. Anyway, I'm obviosuly not going to leave this bug
|
||||
report open for such a minor and tangential issue after the main issue in
|
||||
it is fixed, so it's kind of annoying to need to write this wall of text
|
||||
about it. May I suggest one bug report per distinct issue is a good way to
|
||||
avoid my current annoyed state?
|
||||
|
||||
----
|
||||
|
||||
Not wanting to sit down and write all this is why, the previous two or
|
||||
three times I opened this issue, I promptly closed the window rather than
|
||||
addressing any part of it.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue