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

avoid ugly error message

Browse source 
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:
Joey Hess 2020-01-22 11:39:15 -04:00
parent 8cda10777a
commit d227093002
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 49 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file.mdwn
View file

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

41
doc/bugs/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment Normal file
View file

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