Problem
We use commit-headless push in Datadog Workspaces to ensure all agent-authored commits are signed. This works well for the normal linear commit flow.
However, when a workspace agent rebases a PR branch onto an updated base, the rebased commits are unsigned local rewrites. We need to push them to the remote as signed commits, but:
commit-headless push requires expectedHeadOid to match the current remote branch HEAD. After a rebase, the local history has diverged from the remote, so the first commit's parent doesn't match what's on the remote — the push fails.- We can't use
git push --force-with-lease because that bypasses signing entirely.
Proposed solution
Add a --force flag to commit-headless push that, when combined with --head-sha, allows the first commit's expectedHeadOid to be set to an arbitrary SHA (the new base) rather than requiring it to match the current remote branch HEAD.
Usage would look like:
# After rebasing onto updated main:
git log --oneline main.. | commit-headless push \
--target DataDog/my-repo \
--branch my-feature \
--head-sha "$(git rev-parse main)" \
--forceThe --force flag signals that the branch ref should be updated even though the new parent doesn't match the current remote HEAD. Without --force, behavior is unchanged (the current compare-and-swap semantics).
Why not just re-create the branch?
We considered using --create-branch with a deleted/recreated branch, but that loses PR associations, review comments, and CI status on GitHub.
Context
This came up in dd-source PR #388926 where we're adding rebase detection and push support for workspace agent sessions.
Happy to implement this if it fits the project's goals.
Problem
We use
commit-headless pushin Datadog Workspaces to ensure all agent-authored commits are signed. This works well for the normal linear commit flow.However, when a workspace agent rebases a PR branch onto an updated base, the rebased commits are unsigned local rewrites. We need to push them to the remote as signed commits, but:
commit-headless pushrequiresexpectedHeadOidto match the current remote branch HEAD. After a rebase, the local history has diverged from the remote, so the first commit's parent doesn't match what's on the remote — the push fails.git push --force-with-leasebecause that bypasses signing entirely.Proposed solution
Add a
--forceflag tocommit-headless pushthat, when combined with--head-sha, allows the first commit'sexpectedHeadOidto be set to an arbitrary SHA (the new base) rather than requiring it to match the current remote branch HEAD.Usage would look like:
The
--forceflag signals that the branch ref should be updated even though the new parent doesn't match the current remote HEAD. Without--force, behavior is unchanged (the current compare-and-swap semantics).Why not just re-create the branch?
We considered using
--create-branchwith a deleted/recreated branch, but that loses PR associations, review comments, and CI status on GitHub.Context
This came up in dd-source PR #388926 where we're adding rebase detection and push support for workspace agent sessions.
Happy to implement this if it fits the project's goals.