Webstorm behavior while rebasing from upstream
So I wanted to update my codebase from an upstream/master to "8".

While being in 8, I did:

Then I resolved the conflicts in the rebase/merge dialog
(fyi, here is video proof)
________________________
Now it looks like this:

Bing in the middle of a rebase, I'm inside the upstream branch, which is normal I guess.
Now, I went ahead with:
git rebase --continue
This results in:

Now I'm really confused!
rebase 8 onto onto 41b65bf?
I was in 8 when I typed git rebase upstream/master and then in 41b65bf directly after that.
So I assume 41b65bf is an intermediate branch for the rebase operation.
(41b65bf8 is the revision number for the last commit of the upstream branch.)
The only commit shown in the Vim (I just hate Vim) interface is "init"
Which was the last commit of origin/8.06
______________
I really really hope someone can explain this.
Please sign in to leave a comment.
To make my question more specific:
I'm asking to rebase the 'upstream/master' branch into the '8' branch. via the command 'git rebase upstream/master' from inside (8)
If you look at the very first image, you see the state directly before that. Why wouldn't just the changes from upstream be committed on top of the head? Why does it say 8 on 41b65f? That sounds like the opposite of what I want.
Hello Johannes1 Hoerteis
Could you please clarify why do you choose rebase via cmd over UI? You can do rebase from IDE as well.
In the video I can see that you've only opened "Merge Conflicts" node but haven't resolved conflicts. Could you please check whether 'Resolve' button is still there and active?
You can continue rebase in Branches popup in the bottom right corner.
For now the whole behavior is on a Git side since you are running commands in command line and it's not something that IDE does.
For now, as I can see from your screenshot, you've got a conflict on 41b65f that you haven't resolved yet, so you need to resolve it and then continue the rebase operation. If the same behavior occurs then the hash will be different (it will be a hash of a next conflicting commit)