Error handling improvements

[cloudhead]

Get rid of 99% of unwraps. Make unwraps warn by default, outside of test code.

See commits.

Closes #18

[FintanH]

Re: radicle-dev/radicle-git#29

Ah, I see this actually the blob re-exported. I don't think that should have been re-exported.

[cloudhead]

Hmm, how to handle that then?

[FintanH]

What are you using it for?

[cloudhead]

Actually I think I just use it here: https://github.com/radicle-dev/heartwood/pull/35/files#diff-ba1fcb4b7bb277619ac1f7a10d20d5b2ce6e199046a472cf8fe8f820b046708bR448

[FintanH]

I'd recommend you don't use it unless you're using that blob API in particular :)

Sorry for the confusion!

[cloudhead]

Ok, the thing is it would be nice to have a "good" git error type, which git_ext::Error is pretty close to, or have maybe a RepositoryExt trait that is more flexible. The ref.target() case is a good example of this: most of the time you want the oid of a reference, and this involves repo.find_reference(...)?.target().ok_or(...)? which is cumbersome.

So I use my own methods for getting references, which returns a git_ext::Error, but this requires access to NotFound, so that I can return a "not found" error when the target is missing. Without this, I'd have to create yet another git error type..

[cloudhead]

I've created #38 to track this.

[FintanH]

In this case, you can use https://docs.rs/git2/0.15.0/git2/struct.Repository.html#method.refname_to_id, FYI :)

I'll continue the error discussion in the other issue.

[cloudhead]

Omg I didn't know about this! Life changing!

[FintanH]

lol, I could swear I saw you use it before 😅