-
-
Notifications
You must be signed in to change notification settings - Fork 417
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
Pull request branch not updated when the diff is empty, even though there are changes in the tree #1191
Comments
Hi @oakkitten What state is the PR in after you force push the main branch? Can it still be merged? Or is it complaining that there is a conflict? If this is a rare problem, my inclination would be to suggest dealing with it by closing the PR and letting your workflow reopen it when it next runs. Note that if you don't want to wait for it to rerun you could add the |
I once did run into a situation where there was a conflict so an easy merge wasn't possible. I can resolve the conflict manually, this isn't a big deal. It's just that it seems that this action is designed to keep the PR up to date even if no merge conflicts exist—it seems that there's no way to opt out of that. But in this case the result depends on the state of the branch. I wonder if the issue can also arises if you change the number of new commits, or the order of new commits, or the commit message, or the author, or commiter? (I wonder if simply comparing old and new PR branches while ignoring dates would be suitable here?) But as I said, it's not a big deal. If it's working as intended, sorry for bothering! (P.S., I use this action for dependabot-like pull requests which I merge using fast-forward using another workflow, so I would want the PR branch to not only be conflict free but also fast-forwardable. However I guess there are even fewer people who care about this than those who run into the above issue.) |
When I have some time I'll test this scenario. The action only checks if there is a diff, so changes to commits after a force push on the target branch are probably being ignored. If such changes are leaving the PR in a state where it cannot be merged then I think that is not good behaviour, and perhaps there might be a way to detect that and update the PR by rebasing on to its target. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@oakkitten I tried to reproduce the issue.
After the force push on step 2, the diff of the PR is wrong. I guess this expected and just how git calculates the diff in this situation. However, after the workflow runs in step 3, the PR updates (rebases itself) and corrects the diff. So I'm not seeing any issue here. Am I trying to reproduce this incorrectly? |
This demo repo has some workflows that should reproduce the problem:
|
@bgilbert Thank you for creating that demo repo. It was very useful! I've created a fix for this issue here. I also tested it using the demo repo @bgilbert created. You can see that this PR got updated after the force push of I'm about to go away for ~10 days so I don't want to merge this now, just in case it causes some unexpected issue and I need to roll it back. So you can either wait, or you can use the feature branch temporarily and update to If you want to use the feature branch: - uses: peter-evans/create-pull-request@base-force-push |
Released as Please let me know if/when it is safe to delete the |
Good to delete from my side. Thanks for the fix! |
I suppose that this is working as intended, as the readme says,
But this can lean to a situation where the PR branch (and hence the PR) is not updated even though there are changes in the tree, such as when the main branch was force pushed after rebase. I even ran into a situation with an empty diff and GitHub saying “This branch has conflicts that must be resolved”. While this problem is rare, probably extremely rare, perhaps there's a way to to update PR branch even when the diff is empty?
If you want to reproduce this behavior, force-pushing main branch without changes while PR is pending should trigger the issue if the workflow is set up in a more or less ordinary way. Here's one workflow run with this problem.
The text was updated successfully, but these errors were encountered: