# 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](review-and-sign-off.md)). 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](reviewing-a-change.md)
  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](records-and-manifest-built.md)).