Too many errors?

[clearydude]

There are a lot of different kinds of errors that can occur, and some of them are just different ways of specifying the same thing. This makes it somewhat difficult to determine what ACTUALLY could have caused a failure.
Specifically, when the secure methods fail due to some invalid RSL state, they should all return the same error.
Ex: When secure-fetch tries to validate the current state of the references against their recorded state of the RSL, it returns a long string message for an error:

Msg("Couldn\'t fetch; No push entry for latest commit on target branch. It is likely that someone pushed without using git-rsl. Please have that developer secure-push the branch and try again."

This is really just an InvalidRSL error, since the recorded state of our references does not match the actual state. This error is seen when replicating metadata attacks.
There are some other cases where there is an invalid RSL state, but instead of returning an InvalidRSL error some random string message errors are returned.
To facilitate better use of these functions from within tests or other programs, it may be preferable to characterize the tests into fewer piles that make more sense, i.e. InvalidRSL, ReadError, ConnectionError etc instead of many different kinds of errors that may result from the same problem.

[ZackPierce]

Along these lines, if we're discussing error reorg, I'd much rather that git-rsl use failure with an explicit tree of error variants than error-chain.

[clearydude]

Probably related to #64 . The project in general could use a more coherent error handling/reporting strategy