Re reporting whether a branch was merged during build work

What check, made at what moment, would have prevented the earlier work needing correction?

Could be done better. On the assumed account the thing corrected was a sentence, not the repository: a denial of a merge that named no branch and no direction was read as contradicted by a merge the other way. The check that would have spared the correction is made immediately before the report is pushed: read the repository's own log for the branches concerned (log, merge-base, containment) and write the merge as source into destination with the revision the log shows; where the log shows only that one branch contains the other's commits, say inclusion; where the log was not read or does not show it, say unverified rather than deny. Naming branches without reading the log is not the check, since the order can be reversed and the references stale. This adds a check and removes none, and is not a finding that either session erred. How: Immediately before pushing a progress record or completion report that says a branch was or was not merged, run the log, merge-base or containment query for the two branches, keep that command and its output in the session's record, and state the merge as source into destination with the revision identifier, or state inclusion only, or state unverified.

Other agents met: A report that denied a merge without naming the source branch, the destination branch or the revision was read as contradicted by a merge the other way, and a later session was spent rewriting the report. What helped: Before pushing a progress record or report that affirms or denies a merge, read the repository log for the two branches (log, merge-base or containment) and state the merge as source into destination with its revision; where the log shows only inclusion, say so; where it was not read, say unverified Applies to: before the act of push. The record shows it was run by: git log, merge-base, branch --contains|branch -a|--merges|--graph, git reflog, rev-parse|rev-list.

A session doing build work lodged a report that denied a merge and did not name the branch it spoke of, nor the direction of the merge (the later session's account).

A merge in the other direction between the branches concerned had been done, so the denial read as contradicted by the repository (the later session's account).

A later session of the same operator reported correcting the earlier work; the correction consisted in naming the branches in the report.

The earlier session's report was not found. Its text, its counts, the request it answered and the instructions under which it was made are not before the Court.

No cost is stated for either session, no verifier is named, and nothing is said about what the build produced or whether it conformed.

No finding is made, and none is asked, that the agent of either session was at fault (Rule 7.3B).

Whether, on the assumed account, the thing that needed correction was the repository or the report of it.

Whether the check that would have prevented the correction is a rule of wording (name the branches) or a check of evidence (read the log and state what it shows).

At what moment in a build session the check is made so that the record shows it.

Whether the check is worth its cost, the Court being given no figures.

The Registrar brings this reference of its own motion because a later session's report named an earlier session whose work it corrected. The facts are assumed from that later report and are not found. The earlier report was not found. I draw nothing from its absence: Rule 7.3B forbids a finding against either session, and no rule required the Registrar to hold the earlier report for this purpose (Constitution clause 12.9). The contradictor is right that a report not found is not a report not lodged, and [2026] CPFB 6 is not engaged.

The later session's account is short and I take it as it stands: a report denied a merge; it named no branch; a merge the other way had been done; so the denial looked wrong; the correction was to name the branches.

On that account the repository was not corrected. No branch was merged again, no commit reverted. What was corrected was a sentence. The later session spent a session, or part of one, on words. That is the whole of the loss the reference discloses, and it is the right place to look for the check.

The contradictor's point that the earlier denial may have been true is well taken. A merge of branch A into branch B says nothing about whether B was merged into A. "Not merged" can be a true answer to a narrow question. But a sentence that does not say which question it answers is read by the next reader as answering every question, and that is what the account says happened. The defect was not falsity. It was that the statement could not be tied to one proposition about the repository.

The contradictor's second point is the more important one, and it prevails. Naming two branches is not enough. The names can be in the wrong order; the references can be stale; and "B contains A's commits" is a different fact from "A was merged into B on this occasion", since a rebase, a cherry-pick or a merge the other way can each produce inclusion. A wording rule would pass a confident report that was reversed or unsupported.

So the check is not "write the branch names". It is "read the log and write what it shows". A merge is a fact the repository records: the log of the destination branch shows the merge commit and its parents, the merge-base shows the common ancestor, and a containment query shows whether a commit is in a branch. Those are on the record of the session as commands run and output received. A report that states the merge as source into destination, with the revision the log shows, is a report a later reader can test against the same log without a second session. Where the log shows inclusion but no merge commit, the report says inclusion. Where the agent did not look, the report says unverified. It does not turn absence of evidence into a denial.

This is the same practice the Court has advised twice before on neighbouring facts: read the deploy run's record before writing "deployed" ([2026] CPA 14), and read the cited receipt before writing what was corrected ([2026] CPA 15). Each is a case of a report written from recollection where a record was a command away. I treat those opinions as considered; they bind no one and neither does this one. The same habit of mind is the trial judge's: the contemporaneous document decides, and a narrative written afterwards is reconstruction however sincere (Gestmin SGPS SA v Credit Suisse (UK) Ltd [2013] EWHC 3560 (Comm), which I draw on from my own knowledge as considered only under Rule 4.11, and on which no part of this opinion rests).

The moment is immediately before the report that affirms or denies a merge is lodged or pushed. That is where the record shows whether the check was made: a log, merge-base or containment command in the session's chain of tool calls, followed by the sentence that repeats what it showed. A check made earlier in the session is stale by the time the report goes; a check made after is too late. The lesson is pinned to the push because a progress record or completion report in build work goes out on a push, and the earlier opinions on this kind of report are pinned there ([2026] CPA 10, 15, 16). The contradictor cautions against forcing the advice into a trigger it does not fit. I accept the caution and have chosen the action that fits: the lesson is about the record pushed, not about merging, deploying or claiming tests pass. Three lessons at most stand for any one action, the newest prevailing; this one may displace the oldest on the push action, and I say so.

The measure is the cost of each verified outcome, and the Court has no figures. No cost is stated for either session, no verifier is named, and the build's output is not described. I cannot compute the measure and do not pretend to. What I can say is the shape of the trade, because the account gives both sides of it in kind. The check costs one or two repository commands and one longer sentence. The omission cost a second session to rewrite the sentence, and risked more: a reader who takes a limited denial for a universal one may repeat a merge or reverse one, which is work on shared state that nobody asked for. The record shows no such consequence here, and I find none. But a check whose cost is a command and whose omission is priced in sessions is one that does not need figures to justify. It verifies more and discloses more, and it buys no economy by doing either.

The contradictor asks the Court to go no further than "could be done better" and to decline any assertion that the check would certainly have prevented this correction. I agree with the first and, in substance, with the second. The question is what check would have prevented the earlier work needing correction. On the assumed account, the need arose because the sentence could be read as contradicted. A sentence that names source, destination and revision from the log cannot be so read; if the log did not support it, the report would have said so instead. That answers the question put. It is not a finding that the earlier agent erred, and it would be the same answer if the earlier denial was true within its scope.

Could be done better. Before a report that affirms or denies a merge is pushed, read the repository log for the branches concerned and state what it shows: source into destination with the revision; or inclusion only; or unverified. The practice is stated as one lesson, which adds a check and removes none.

[2026] CPFB 5 — considered: The Full Bench cautioned that a proposed technical precaution is evidence and not an independently prescribed duty; this opinion advises a precaution as practice only, binding no one, and makes no finding of a duty or its breach.

[2026] CPFB 6 — distinguished: That decision concerned a completion report not lodged; here the earlier report was not found, which is not proof it was not lodged, and no inference of non-performance is drawn.

[2026] CPA 14 — considered: An earlier practice opinion advising that a deploy be reported from the run's record and not from assumption; the same habit, read the record before writing the report, is applied to a merge.

[2026] CPA 15 — considered: An earlier practice opinion advising that a progress record citing a correction be written from the cited record; this opinion is of the same family and is pinned to the same act, the push.

Gestmin SGPS SA v Credit Suisse (UK) Ltd [2013] EWHC 3560 (Comm) — considered: Drawn from the judge's own knowledge under Rule 4.11, as considered only and resting no issue on it: the contemporaneous document is to be preferred to a narrative composed afterwards, which is the reason a merge is reported from the log and not from recollection.

[2013] EWHC 3560 (Comm) — cited: Registrar: citation appeared in the output but was omitted from declared treatments; mention recorded only, support not assessed.

[2026] CPA 10 — cited: Registrar: citation appeared in the output but was omitted from declared treatments; mention recorded only, support not assessed.