This change was inspired by the a story as old as time:

𝕃𝕖𝕥 𝕦𝕤 𝕞𝕚𝕩 𝕠𝕦𝕣 𝕓𝕦𝕤𝕚𝕟𝕖𝕤𝕤 𝕝𝕠𝕘𝕚𝕔 𝕨𝕚𝕥𝕙 𝕠𝕦𝕣 𝕀𝕆!

It was motivated by the fact that the canonical quorum logic was spread across two modules and also two different repositories (in the API sense). The radicle-remote-helper contained special logic for computing the quorum, and also relied on the logic with radicle itself. It would also mix using the Radicle storage repository and the working copy repository – resulting in issues where objects could exist in one and not the other.

The change begins by separating away the IO away from any of the business logic in the git::canonical module. To follow along, there are two important submodules:

1. voting captures the different type of voting processes for commits and tags a. Tags are simple, where one Oid means one vote b. Commits are slightly more complicated. They begin with one Oid means one vote, but then it is expected that merge bases are calculated for pairs of commits. These merge bases are used to increase a vote for an Oid if it is the merge base of another commit.
2. quorum builds on top of voting and uses the voting processes as well as the threshold to find the quorum for the tag or commit reference. a. For tags, the first past the threshold wins, but if multiple pass then it is an error. b. For commits, the merge base process should be used to increase the votes, until the caller is ready to find the quorum. At this point, the commits that pass the threshold are then compared to find the commit that is the child-most commit of all other candidates. If they diverge, then an error is returned.

There is also a convergence module that captures the logic that is required for the radicle-remote-helper. It essentially checks if a candidate object matches the expected objects, tags or commits, and performs the necessary convergence logic – checking that the candidate commit is converging with at least of the other Dids.

These two quorum processes, and the convergence process, essentially act as state machines and can be driven by the use of a Git repository for finding the merge bases. This is where the effects module comes in. The effects capture the necessary traits that are required to drive the state machines of the quorum processes. It is expected that a Git repository implements these, and in fact, a git2::Repository implementation is provided. The traits are useful, since it means that a git2::Repository can be swapped out and the logic would stay the same.

This all culminates into the new and improved Canonical and CanonicalWithConvergence. Both of which have methods find_quorum for performing the quorum process using a single provided repository.

This resulted in the semantic change of requiring that the radicle-remote-helper pushes the candidate commit, irregardless of whether it will be a fast-forward. For now, this is something that will be accepted while the UX can be improved in the future by providing detailed warnings of the divergence and ways to fix it. The benefit is that the tooling will never stop someone from diverging if that is in fact what they want to do.

Changes:

• Removed extra newline

Review

Changes:

• Rebased
• Accepted review changes

Rebase