Summary
gh stack push is documented as pushing every active branch with --force-with-lease --atomic, but the command currently invokes the Git push layer with atomicity disabled.
This is present in both v0.0.8 and the current main branch.
Current behavior
runPush calls:
git.Push(remote, activeBranches, true, false)
The fourth argument is atomic, so this requests lease-protected pushing without --atomic:
The command test also explicitly expects atomic to be false:
Meanwhile, the command help and documentation say the operation uses --force-with-lease --atomic to provide all-or-nothing updates.
Impact
The explicit per-branch leases are strong and prevent overwriting unexpected remote changes. However, without --atomic, a multi-branch push may update some stack branches before another branch is rejected. That can leave the remote stack partially updated despite the documented all-or-nothing guarantee.
This distinction matters for automation that treats a rejected stack push as proof that no remote branch changed.
Expected behavior
gh stack push should pass atomic=true when pushing the active branches, consistent with its help text and documentation.
It would also be useful to add a test that rejects one ref in a multi-ref push and verifies that none of the remote refs update.
Summary
gh stack pushis documented as pushing every active branch with--force-with-lease --atomic, but the command currently invokes the Git push layer with atomicity disabled.This is present in both
v0.0.8and the currentmainbranch.Current behavior
runPushcalls:The fourth argument is
atomic, so this requests lease-protected pushing without--atomic:cmd/push.gointernal/git/gitops.goThe command test also explicitly expects
atomicto be false:cmd/push_test.goMeanwhile, the command help and documentation say the operation uses
--force-with-lease --atomicto provide all-or-nothing updates.Impact
The explicit per-branch leases are strong and prevent overwriting unexpected remote changes. However, without
--atomic, a multi-branch push may update some stack branches before another branch is rejected. That can leave the remote stack partially updated despite the documented all-or-nothing guarantee.This distinction matters for automation that treats a rejected stack push as proof that no remote branch changed.
Expected behavior
gh stack pushshould passatomic=truewhen pushing the active branches, consistent with its help text and documentation.It would also be useful to add a test that rejects one ref in a multi-ref push and verifies that none of the remote refs update.