You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a way to sync a stack from the remote without pushing #516
When a stack has been restacked and force-pushed from elsewhere either by a collaborator, or the rebase option on gh webapp my local branches are left with the pre-rebase SHAs. With stack view every branch shows as ahead N, behind N against its remote, but the "ahead" commits are just stale copies of work that's already upstream under different hashes.
What I want in that situation is "make my local stack match the remote". as far as I am aware gh stack sync is close to doing this, but it always pushes (--force-with-lease --atomic), which is the opposite direction, and there's no flag to stop it.
It also doesn't just no-op, it rebases those stale local commits onto the updated parents, which replays commits that are already upstream. I ended up with empty duplicate commits on a branch that way, including one that kept its original co-authors on a no-op.
So what I end up doing when I want my local to match the remote stack is:
git fetch --all --prune
for every stack branch git branch -f "$branch""origin/$b"
I think a good solution would be either a flag on sync (--no-push, or a --reset/--from-remote mode) or a separate
command, that fetches and points each local stack branch at its remote without rebasing or pushing anything. You could even have sync detect this case where local is ahead only by commits whose patch-id already exists upstream rather than directly with a flag.
Activity
Romex91 commentedon Sep 22, 2026
@alasdairwilson I wrote workaround for your use case: https://github.com/Romex91/gh-stack-pull
gh extension install Romex91/gh-stack-pull gh stack-pull gh stack-pull --rebase # in case of divergent branchesThere are so many edge cases, if something doesn't work for you, I'd appreciate reproduction steps.
Romex91 commentedon Sep 22, 2026
I hope Microsoft will take a look at the tests I added when implementing their version of the command. Too many edge cases.