gitbutler icon indicating copy to clipboard operation
gitbutler copied to clipboard

Push Stack error and force push create a PR to the wrong remote branch

Open CGQAQ opened this issue 7 months ago • 2 comments

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,

Image

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."

CGQAQ avatar May 16 '25 02:05 CGQAQ

After click the bottom force push, it worked, but the force push is very scary, what was it actually do in the gitbuter term?

CGQAQ avatar May 16 '25 02:05 CGQAQ

Now I know Force push was a wrong move, it results PR to wrong branch:

Image

Image

CGQAQ avatar May 16 '25 02:05 CGQAQ

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.

Byron avatar May 18 '25 18:05 Byron