Skip to content
Start free
Code mode

Stay in sync after a merge

Keep M1rror up to date when your default branch moves, avoid re-approving builds for unrelated commits, read the changelog of merged work and open a revert pull request.

On this page

Your repository keeps moving after a design ships. M1rror follows it: it picks up new commits on your default branch, keeps a changelog of the implementation pull requests that merged, and can open a pull request that reverts one if you need to back it out.

Updates when you push

When someone pushes to the repository's default branch, or the branch M1rror tracks, the GitHub App tells M1rror. M1rror then fetches the new commits and reads the toolchain again.

If Re-scan for drift when the default branch moves is on (it is by default; the switch is in the Toolchain section of Code's Repository panel) and the repository has been scanned before, M1rror also scans the new commit. That way design drift that merged shows up without anyone asking. Each scan is a normal scan and uses your plan's usage allowance; turn the switch off if you'd rather scan by hand.

Pushes to other branches, tags and deleted branches are ignored.

No re-approval for unrelated commits

A build plan is authorised against a specific base commit. If the base branch moves on before the build runs, M1rror still runs it on the new commit, and says so, when all of these are true:

  • the new commit comes after the approved one;
  • it is at most 200 commits ahead;
  • none of the new commits touch the files the plan is allowed to change.

Otherwise the plan is out of date, and you prepare and authorise a new one.

The changelog

Each implementation pull request that merges adds one entry to the Changelog in Code's Repository panel: the release it implemented, the pull request, the merge commit, who merged it and when, how many files it changed and a short summary.

Coding agents can read the same list with taste_list_implementation_changelog.

Revert a merged implementation

If a merged implementation needs to come out, M1rror can prepare the revert for you as a draft pull request.

  1. Open the merged build

    Open Ship mode › Build and open the build whose pull request merged.

  2. Ask for the revert

    Select Open a revert PR. You need permission to authorise implementations (the Repository role). The dialog explains what happens; select Open revert PR to go ahead, or Keep it.

  3. Review and merge it in GitHub

    M1rror reverts the merge commit on the current head of your base branch, pushes a branch named m1rror/revert-<branch> without force-pushing and opens a draft pull request. Your team reviews and merges it like any other change. M1rror never merges it.

The revert's status shows next to the build and in the changelog: Opening revert, Revert PR open, Reverted, Revert closed or Revert failed. Each implementation pull request gets at most one revert pull request.

If something goes wrong

  • The revert has a conflict. Later commits changed the same lines. M1rror reports the conflict and pushes nothing. Revert it by hand in your repository.
  • "Not available here." The GitHub App on that account hasn't accepted write access to contents and pull requests, which the revert uses in the same way as opening a pull request. Accept the permissions in GitHub, then try again.
  • "Someone who can authorize implementations can open a revert PR." Ask someone with the Repository role. See members and roles.

Last updated

Edit this page on GitHub