Better error msgs

[rand00]

No description provided.

[dinosaure]

That's indeed a good way (we probably should print out which branch we want to clone).

[rand00]

Which branch are you thinking about? My thinking was that the user knows what branch is passed, and multiple possible branches can be present - so I wouldn't know what branch to suggest

[reynir]

In the remote used by git-kv you can optionally specify a branch. It seems git-kv doesn't have a function to get the branch used - it may not be obvious what the default branch is, and I believe it changed from master to main a few months back.

[dinosaure]

Indeed, on Debian, the default branch still is master and we currently occur several cases where people don't really understand this kind of failure. I will try to provide an accessor on git-kv to get the branch used.

[hannesm]

Thanks for your PR. I agree that the branch that was cloned could be part of the "better error msgs".

But I've an issue with a failwith that may happen at any point in time (whenever the update-hook is invoked) -- leading to the unikernel exiting.

Could we instead have such an exceptional failure only when at startup the remote is not reachable / cloned an empty repository, please? I agree that the current behavour (Result.get_ok last_hash) is as well leading to termination, so we should improve on that front.

So what is the desired semantics?

• on startup, if the remote git repo (+branch) is empty, terminate
• in the middle of the run, when update is invoked, log an error when the git repo or branch disappeared (at the moment, an internal server error is reported to the client doing the update, with the error from the git clone)

Any other ideas?

[rand00]

Now retrieve_last_commit returns a Lwt_result.t, which can be handled as needed on callsite.

Instead of handling this error differently from others, I made all internal server errors in dispatch log error msg instead