`gh stack push` advertises atomic updates but invokes `git.Push` with atomic disabled
- Dominant language
- Go
- Stars
- 1.5k
- Forks
- 70
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 7
Description
## 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:
```go
git.Push(remote, activeBranches, true, false)
```
The fourth argument is `atomic`, so this requests lease-protected pushing without `--atomic`:
- [`cmd/push.go`](https://github.com/github/gh-stack/blob/v0.0.8/cmd/push.go#L104-L110)
- [`internal/git/gitops.go`](https://github.com/github/gh-stack/blob/v0.0.8/internal/git/gitops.go#L169-L201)
The command test also explicitly expects `atomic` to be false:
- [`cmd/push_test.go`](https://github.com/github/gh-stack/blob/v0.0.8/cmd/push_test.go#L60-L66)
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.
Contributor guide
Research direction
Start in cmd/push.go at runPush and inspect the atomic argument passed to git.Push; then read internal/git/gitops.go to confirm how that option reaches Git. Use cmd/push_test.go as the existing command-level test, and add coverage for a rejected ref in a multi-ref push. Done means the command behavior matches its documented all-or-nothing guarantee.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, go
- Domain
- cli, testing
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 75/100