Surface: the buyer merge path (merge_retained_commit). Cites at f19389e.
Labels: design, buyer
Problem
§8.1 permits exactly one commit, parented on the pinned base. So N parallel contribution jobs on one base give N sibling commits.
merge_retained_commit (delivery_git.rs:469) accepts a fast-forward only. It returns MergeFailed("ff-only") when the analysis is not a fast-forward (delivery_git.rs:493).
So the first sibling merges, and every later sibling fails. A buyer that splits work across sellers cannot merge the results into one branch.
A seller cannot merge either
§8.1 says an implementation MUST assert a parent count of one in contribution mode, and a parent count of zero in greenfield mode. A merge commit has two parents or more.
So no delivery can carry a merge commit. A buyer cannot buy the merge as a job. The merge must run on the buyer side, or the protocol must change.
Options
Option A — a real merge in the buyer store. Replace the fast-forward step with a true merge. It needs a path for a conflict, and nothing in the tree has one today.
Option B — run the parts one after another. Pin part N+1 to the tip after part N merges. Each merge stays a fast-forward, so merge_retained_commit works without a change. The parts lose their parallel run.
Option C — rebase each sibling. The buyer replays sibling N onto the current tip, then fast-forwards. It keeps merge_retained_commit. But a rebase writes a new commit oid, and the money path bound the original oid. The receipt then names a commit that the branch does not hold.
Option B needs no code. Option A and Option C both need new code in the buyer store.
Out of scope
Multi-turn on one chain. #948 covers that, and a sequential thread never reaches this limit.
Unverified
merge_retained_commit has zero production callers, so nothing runs this path today. No runtime measurement.
Surface: the buyer merge path (
merge_retained_commit). Cites atf19389e.Labels: design, buyer
Problem
§8.1 permits exactly one commit, parented on the pinned base. So N parallel contribution jobs on one base give N sibling commits.
merge_retained_commit(delivery_git.rs:469) accepts a fast-forward only. It returnsMergeFailed("ff-only")when the analysis is not a fast-forward (delivery_git.rs:493).So the first sibling merges, and every later sibling fails. A buyer that splits work across sellers cannot merge the results into one branch.
A seller cannot merge either
§8.1 says an implementation MUST assert a parent count of one in contribution mode, and a parent count of zero in greenfield mode. A merge commit has two parents or more.
So no delivery can carry a merge commit. A buyer cannot buy the merge as a job. The merge must run on the buyer side, or the protocol must change.
Options
Option A — a real merge in the buyer store. Replace the fast-forward step with a true merge. It needs a path for a conflict, and nothing in the tree has one today.
Option B — run the parts one after another. Pin part N+1 to the tip after part N merges. Each merge stays a fast-forward, so
merge_retained_commitworks without a change. The parts lose their parallel run.Option C — rebase each sibling. The buyer replays sibling N onto the current tip, then fast-forwards. It keeps
merge_retained_commit. But a rebase writes a new commit oid, and the money path bound the original oid. The receipt then names a commit that the branch does not hold.Option B needs no code. Option A and Option C both need new code in the buyer store.
Out of scope
Multi-turn on one chain. #948 covers that, and a sequential thread never reaches this limit.
Unverified
merge_retained_commithas zero production callers, so nothing runs this path today. No runtime measurement.