packport has no answer for a line main has moved past #320

Open
opened 2026-08-18 10:07:30 +00:00 by PerishFire · 1 comment
Owner

plumb stable packport asks Forgejo for a plain merge of the release line into main. That works while main has not moved, which is the common case when a release is quick.

v0.26.0 was not quick. The line absorbed eleven fixes while main absorbed the same eleven, and the two diverged on plumb.toml seals, generator.rs, the rendered lanes and the changelog. The merge conflicted, and packport stopped with:

plumb stable: forgejo refused pull merge 317 on PerishLab/plumb: Please try again later

(That message is at least legible now — naming the operation landed this cycle.)

What packport means

Packport settles ancestry. It does not carry content: everything on the line is already on main, arriving there as the commits that were picked from it. The only line-only content is the datum, which is line state.

So the merge that settles it is the one that keeps main's tree exactly and records the line as a second parent — git merge -s ours. That is what was done by hand to finish v0.26.0:

36af308 Packport v0.26.0
  parents: dd42b90 (main) 831223a (release/v0.26.0)
  diff against main: empty

The ask

plumb stable packport should settle ancestry the way it means to, whatever main has done since the line was cut, rather than the way a plain merge happens to work when nothing has. The refusal it needs is not "these conflict" — there is nothing to conflict about — but the ancestry proof it already runs afterwards.

Related: the same release exposed that a late packport collides, which prepare and freeze now refuse outright (main 4c16f90). This is the other half: a packport that is not late can still be unreachable.

`plumb stable packport` asks Forgejo for a plain merge of the release line into main. That works while main has not moved, which is the common case when a release is quick. v0.26.0 was not quick. The line absorbed eleven fixes while main absorbed the same eleven, and the two diverged on `plumb.toml` seals, `generator.rs`, the rendered lanes and the changelog. The merge conflicted, and packport stopped with: ``` plumb stable: forgejo refused pull merge 317 on PerishLab/plumb: Please try again later ``` (That message is at least legible now — naming the operation landed this cycle.) ## What packport means Packport settles ancestry. It does not carry content: everything on the line is already on main, arriving there as the commits that were picked from it. The only line-only content is the datum, which is line state. So the merge that settles it is the one that keeps main's tree exactly and records the line as a second parent — `git merge -s ours`. That is what was done by hand to finish v0.26.0: ``` 36af308 Packport v0.26.0 parents: dd42b90 (main) 831223a (release/v0.26.0) diff against main: empty ``` ## The ask `plumb stable packport` should settle ancestry the way it means to, whatever main has done since the line was cut, rather than the way a plain merge happens to work when nothing has. The refusal it needs is not "these conflict" — there is nothing to conflict about — but the ancestry proof it already runs afterwards. Related: the same release exposed that a late packport collides, which `prepare` and `freeze` now refuse outright (main `4c16f90`). This is the other half: a packport that is not late can still be unreachable.
Author
Owner

Perish's call: packport is bookkeeping after publication, nothing is broken when it fails, and a hand-settled merge every twenty releases is cheaper than mechanising one. Documented instead, on main cb6d9bc.

The brief names the resolution rather than the problem, which is the part that matters here. "Resolve the conflicts" would be read the ordinary way — merge content file by file — and that changes main's tree while looking like a job well done. Packport carries no content: every commit on the line was picked from main, and the datum is the line's own state. So the brief says take main's tree entire, record the line as a second parent, and check the two things that make it right: an empty diff against main, and the stable commit reachable from the result.

Left open rather than closed, because the instruction is now one deterministic command with two checks — which is a mechanism's shape, if it ever earns its place.

Perish's call: packport is bookkeeping after publication, nothing is broken when it fails, and a hand-settled merge every twenty releases is cheaper than mechanising one. Documented instead, on main `cb6d9bc`. The brief names the resolution rather than the problem, which is the part that matters here. "Resolve the conflicts" would be read the ordinary way — merge content file by file — and that changes main's tree while looking like a job well done. Packport carries no content: every commit on the line was picked from main, and the datum is the line's own state. So the brief says take main's tree entire, record the line as a second parent, and check the two things that make it right: an empty diff against main, and the stable commit reachable from the result. Left open rather than closed, because the instruction is now one deterministic command with two checks — which is a mechanism's shape, if it ever earns its place.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
PerishLab/plumb#320
No description provided.