Module already 

Is a branch’s change already in the base under a different commit id?

The same change can reach the base twice over: a candidate’s commit is cherry-picked or squashed in by another task, and from then on the original branch is a pile of commits main has no ancestry link to. Base sync would try to rebase it and report a conflict with itself, and a pull request or queue task for it would sit open for ever because the forge never saw that branch merge.

already_in is the pure decision and classify feeds it from git. Two proofs are accepted, and nothing else:

• patch-id: (together with the tree check below, so a later revert on the base is not mistaken for presence) every commit the branch adds has a - line in git cherry <base> <branch>, i.e. the base carries a commit with the same diff. A merge commit has no patch-id, so a branch with one is never proven this way.
• tree: merging the branch into the base changes nothing, which also covers a squash of several commits into one.

A branch that is only partly in the base, or whose re-land needed a conflict resolution (so its patch-id changed), is AlreadyIn::No: a miss costs an operator a look, a false positive would close live work.

Structs

Evidence

Where the branch’s change lives on the base.

Enums

AlreadyIn

The verdict of already_in.

Proof

Which proof established that a branch is already in the base.

Functions

already_in

Pure decision. added is every commit in <merge-base>..<branch>; unmatched and matched are the + and - lines of git cherry; tree_unchanged says a merge of the branch into the base left the base’s tree as it was.

classify

Ask git whether head is already represented in base. Both are pinned to ids first so a ref that moves mid-check cannot split the answer.

short_sha

The first seven characters of an object id.