Include more repository status details in the /status response.

[foot]

Currently we have configured: true|false.

It would be really cool to be able to show that we've detected a repository at the URL you've provided, but cannot read/write it with the keys we have.

We could then give the user more hints about what they should be doing next in the configuration process.

found: true|false could work?

• found: false, configured: false: check your repo addr
• found: true, configured: false: check your permissions
• configured: true: happy days!

WDYT?

[foot]

UI thought: Interpretation of :error should change from RED to YELLOW perhaps too. We use it for "cloning repo..." and other stuff.

[squaremo]

A bit of implementation detail ... the /status API in the service uses two RPCs to the daemon:

• GitRepoConfig, which reports the {URL, branch, path} triple and the public key (potentially generating the latter); then, provided that succeeds,
• SyncStatus, which is taken as an indication of whether the git repo has been cloned and thereby everything is cool -- if that doesn't return an error, configured is set to true.

We can include more information in the first call, like whether the git repo in question has been cloned, and is writable (given #865). Enough so that the second call will be redundant, except for backward-compatibility.

[foot]

In conclusion!: We can't really differentiate between "does it exist" and "do we have access". Read vs. Write in the error message is a nice addition from #865 though.

[foot]

Would still be useful to report whether we can write to the repo and if we've been able to clone it!

[squaremo]

@foot I think we do report more on the specific repo status now, can you check when you have a sec, and close if it's satisfactory...

[foot]

Yep, the newer API responses here let us see write/cloned. 👌