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:
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

View file

@ -15,6 +15,8 @@ git-annex (7.20191231) UNRELEASED; urgency=medium
git annex initremote type=directory encryption=none --whatelse
* Added LISTCONFIGS to external special remote protocol. Special remote
programs that use GETCONFIG/SETCONFIG are recommended to implement it.
* init: Avoid an ugly error message when http remote has no git-annex
uuid configured.
-- Joey Hess <id@joeyh.name> Wed, 01 Jan 2020 12:51:40 -0400

View file

@ -248,7 +248,7 @@ tryGitConfigRead autoinit r
| haveconfig r = return r -- already read
| Git.repoIsSsh r = storeUpdatedRemote $ do
v <- Ssh.onRemote NoConsumeStdin r
(pipedconfig, return (Left $ giveup "configlist failed"))
(pipedconfig autoinit, return (Left $ giveup "configlist failed"))
"configlist" [] configlistfields
case v of
Right r'
@ -263,11 +263,11 @@ tryGitConfigRead autoinit r
where
haveconfig = not . M.null . Git.config
pipedconfig cmd params = do
pipedconfig mustincludeuuuid cmd params = do
v <- liftIO $ Git.Config.fromPipe r cmd params
case v of
Right (r', val) -> do
unless (isUUIDConfigured r' || S.null val) $ do
unless (isUUIDConfigured r' || S.null val || not mustincludeuuuid) $ do
warning $ "Failed to get annex.uuid configuration of repository " ++ Git.repoDescribe r
warning $ "Instead, got: " ++ show val
warning $ "This is unexpected; please check the network transport!"
@ -279,7 +279,7 @@ tryGitConfigRead autoinit r
liftIO $ hClose h
let url = Git.repoLocation r ++ "/config"
ifM (liftIO $ Url.downloadQuiet nullMeterUpdate url tmpfile uo)
( Just <$> pipedconfig "git" [Param "config", Param "--null", Param "--list", Param "--file", File tmpfile]
( Just <$> pipedconfig False "git" [Param "config", Param "--null", Param "--list", Param "--file", File tmpfile]
, return Nothing
)
case v of

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

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