Comparing two builds

Every review is a diff of two manifests. The after side is your working tree. The before side is a git ref.

By default, the before side is the repository's default branch (main or master, read from the git remote) at its merge base with your current branch, as a pull request's diff is. So changes merged into the default branch since you branched don't show as reversed. On the default branch itself, the before side is the previous commit. Pass --before <branch or commit> to compare with anything else. The same default serves check, jadpo approval and the review web view.

The compiler reads that commit from git, builds it with the same compiler, and caches its manifest in build/before/<commit>/, so this costs one build per base commit.

• jadpo check uses the diff to fail on any change that needs a person and hasn't been accepted (Review and sign-off). In CI, the base commit must be fetched: a full clone, not a depth-1 checkout.
• jadpo approval explains the same diff as Markdown and JSON in build/review/, decisions first, in the order Reviewing a change gives. For production, pass the commit that the deployed build's events carry.
• Records come with it. The API record's diff, the migrations added, the lock changes and the acceptances added are part of the before and after trees, so the review lists them without a second mechanism.
• A base that doesn't compile. If the base doesn't compile with this compiler, for example after a language upgrade, check compares the records only and says so. Upgrade the compiler in its own change.

jadpo approval isn't built yet (What is built).