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
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
Reference in a new issue