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

move comment to right bug and simplify another

Browse source
This commit is contained in:
Joey Hess 2020-02-03 12:51:28 -04:00
parent 818d140748
commit a75aeb5ff4
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 4 additions and 28 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
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
View file

@ -3,39 +3,15 @@
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
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?
The actual bug here is that it dumps git config to stderr at all.
----
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.
The extra newlines are output to stdout, so not a problem WRT stderr.
"""]]

2
doc/bugs/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_5_495820d777c889f88466d725c11895f9._comment → 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_2_495820d777c889f88466d725c11895f9._comment
View file

@ -1,6 +1,6 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
subject="""comment 2"""
date="2020-01-22T17:04:09Z"
content="""
Error message has been improved.