Skip to content
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

Conflicts should be resolved after backporting missing PR's #5121

Open
soyacz opened this issue Aug 7, 2024 · 3 comments
Open

Conflicts should be resolved after backporting missing PR's #5121

soyacz opened this issue Aug 7, 2024 · 3 comments

Comments

@soyacz
Copy link

soyacz commented Aug 7, 2024

Expected Behavior

When trying to backport one PR, I figure out that previous one was missing causing conflicts.
So, first I backport previous one and I expect the initial one conflicts to be fixed.

Actual Behavior

Conflicts stay and need to resolve them manually.

Steps to Reproduce the Problem

  1. Create 2 PR's that change the same thing
  2. Try to backport the second one - cause conflict
  3. Backport 1st one - see still conflicts are present
@jd
Copy link
Member

jd commented Aug 7, 2024

Backports are not automatically updated in any way and that's not something we're planning to do.
Best case would be to be able to recreate a backport, which would work in your case. Though I think this is something that we don't allow yet.

@fruch
Copy link

fruch commented Aug 7, 2024

Backports are not automatically updated in any way and that's not something we're planning to do. Best case would be to be able to recreate a backport, which would work in your case. Though I think this is something that we don't allow yet.

thanks for the prompt response @jd

if there something that could be done to help with such flow ? we have them on a daily basis, that we need to backport to 5-6 branches, and even if 2 of 6 is having this, the manual intervention is not always trivial, and cannot be automated...

@fruch
Copy link

fruch commented Aug 7, 2024

also trying using @mergify rebase command, which in this situations, cause more harm, and all of the conflicts in code are duplicated, and it ends up harder to solve them.

I would expect a rebase command to work as rebase does, take the changes out, and apply the original changeset ontop of the updated target branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants