-
Notifications
You must be signed in to change notification settings - Fork 552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve upstream squashed commit detection #5818
Comments
Thanks a lot for reporting, and the sequence of pictures makes it very straightforward to follow what's happening. I tried to follow the steps, created one base PR and another dependent one. When merging the base PR, I got a couple of errors - I think this is due to me accidentally clicking the button twice or thrice even. CC @mtsgrd in case there is a way to generally solve 'async-button' problem. Then I update the workspace… …and it went through, leaving only the commit in the secondary branch, like one would expect. So my feeling is that in the case described in this issue the conflict prevented this from working correctly, and follow-up operations accumulated more error. I would hope that the changes in #5722 and related PRs can help with preventing such conflicts that shouldn't be, but it's only a guess for now. Also CC @Caleb-T-Owens as rebasing is probably involved. |
Good I'm glad it helped, I have a full recording of the events too if you need it 👍 |
Hi @ionTea, Could you let me know what merge stratergy you use on GitHub, IE "Merge", "Squash and Rebase", or "Rebase"? Thanks |
Sorry for the slow response, we use "Squash and Merge" 🙂 |
No worries! I believe the "Cannot change pr base branch..." message has now been resolved. As for the other issues, I believe this is in a large part due to the complexity of trying to detect whether a set of commits are part of one larger squashed commit, especially in any I would recommend using either the I'm going to rename this issue to track this squashed commit detection problem. |
I took another look and in theory, gitbutler/crates/gitbutler-branch-actions/src/virtual.rs Lines 1044 to 1057 in a0f601b
However, squashed or not, ideally that target commit is not too advanced so it didn't diverge too much. When looking at the following blob-merge as example: mkdir partial-match-2
(cd partial-match-2
cat <<EOF > base.blob
0
1
2
3
4
5
EOF
cat <<EOF > ours.blob
0
X1
X2
X3
X4
5
EOF
cat <<EOF > theirs.blob
0
1
X2
X3
4
5
EOF
) Then the diff will be conflicting as the states differ, even though the changes are overlapping.
Probably there is a way to devise an algorithm to check if only the changes are included on the other side and call it good if that's the case. The merge algorithm already normalizes the regions to compare and fills in the common ancestor (lines |
I've come up with an algorithm that should be much more accurate. I'll have a go at implementing it tomorrow. https://gitbutler.notion.site/correctly-detecting-squashed-integration |
I took a look at the linked document, but immediately admit that I couldn't follow. This doesn't mean anything though, just that whatever I share here isn't based on something you might already have written down or clarified. There is just one question that came to my mind while thinking about this: If there are three commits, I am glad you seem to be having a solution though, hoping that eventually I also arrive there 😅. |
Version
0.14.3
Operating System
macOS
Distribution Method
dmg (Apple Silicon)
Describe the issue
I really like the addition of stacked PRs, but there seems to be some issue when the base of a stack is merged into master and the rest of the branches on the stack needs to rebase.
I took some screen shots to show what happens.
Here I got a stack with two PRs, and the base has been merged into master
I want to update my stack so the
So I update my workspace - no issues indicated so far:
But now all of a sudden my remaining PR in the stack has a new commit that wasn't there before, and it somehow conflicts with the version I have on remote?
I don't want to deal with any conflicts, since I know the remote version of this branch was fine, so I reset to remote.
But now my branch has the commit I had from my previous PR, which was integrated?
So I guess I just don't know what to do to handle this? What I did now was that I manually went through each of the commits that were in the old branch and just uncommitted them, so my branch only included the commits you see in my first image. That's what I would expect.
Am I using this feature wrong? How am I supposed to manage stacks when the base is merged?
How to reproduce
See the issue description
Expected behavior
I would expect that the PRs look the same and contain the same commits after a part of the stack is merged
Relevant log output
No response
The text was updated successfully, but these errors were encountered: