Push Stack error and force push create a PR to the wrong remote branch
Version
0.14.23
Operating System
Windows
Distribution Method
msi (Windows)
Describe the issue
add new branch to stack of two, part of the stack is merged,
ipc.ts:76
ipc->stack_details: {"projectId":"53710ae2-b1dc-473f-abf2-2a45cfb14a1f","stackId":"c9e36719-b672-4406-ae0e-385ab59e6129"}
"branch with ID c9e36719-b672-4406-ae0e-385ab59e6129 not found"
ipc->push_stack: {"projectId":"53710ae2-b1dc-473f-abf2-2a45cfb14a1f","stackId":"3d5e3753-6c9a-4811-8178-e29858317a85","withForce":false}
"git command exited with non-zero exit code 1: ["push", "--quiet", "--no-verify", "origin", "7ff4ac8feba17b87b776e49fce74a6c0f0d05d78:refs/heads/review-pr-prompt"]
STDOUT:
STDERR:
To github.com:unit-mesh/autodev-workbench.git
! [rejected] 7ff4ac8feba17b87b776e49fce74a6c0f0d05d78 -> review-pr-prompt (non-fast-forward)
error: failed to push some refs to 'github.com:unit-mesh/autodev-workbench.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you want to integrate the remote changes, use 'git pull'
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details."
After click the bottom force push, it worked, but the force push is very scary, what was it actually do in the gitbuter term?
Now I know Force push was a wrong move, it results PR to wrong branch:
Thanks a lot for reporting!
From the screenshots I can tell that the local and remote tracking branches have diverged, something that can easily happen after a workspace update. Then a force-push is required to bring the branch on the remote back 'in sync'.
The second screenshot shows that the branch was merged on the remote, and it seems that it was merged into a branch that wasn't the same as the remote tracking branch that GitButler recorded locally. But I am not entirely sure as GitButler calls it BaseBranch internally.
I am sure this will get a revision in the upcoming major release, which should make it easier to follow and more predictable.
Lastly, from the logs above it's also clear that GitButler offered to push even though that wasn't possible, which might be an issue with the analysis of the commit-graph.