How to merge when conflicts exist

[saschanaz]

I want to push a merge commit where the conflicting files are rewritten by the tool.

Background:

I have a tool named webidl-updater to read Web IDL from web specifications and send pull requests to modify their syntax problems automatically.

The PRs frequently get merge conflicts since the specs are being actively updated, but there is no way to solve the conflicts solely with Octokit REST API.

Currently the tool just opens a new PR whenever conflict happens, which is suboptimal. (See w3c/csswg-drafts#4385 and w3c/csswg-drafts#4798.)

[gr2m]

Hi @saschanaz, very cool to see that you use Octokit for the CSS Working Group drafts!

Just so I understand it right: you want your bot account to create merge commits to resolve conflicts in current pull requests? In the forceUpdateToLatestCommit() method?

Is the use case to basically rebase open pull requests on latest master?

[saschanaz]

Just so I understand it right

Right, but only for existing PRs that the bot opened, because the bot knows what should be done for them.

Is the use case to basically rebase open pull requests on latest master?

That's what I do as a workaround for now, but rebasing always closes existing PRs and thus causes a need to open new PRs whenever conflicts happen.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gr2m]

but rebasing always closes existing PRs and thus causes a need to open new PRs whenever conflicts happen

@bcoe I think you run into this challenge before? Did you end up resolving it?

[bcoe]

👋 for our case, we always update the branch from master as we're creating new PRs, and I believe hav rarely run into conflicts (@chingor13 did manage to get into a conflicting state once, and I don't know that we got to the bottom of it, perhaps he can speak to this).

The problem we were running into, was making the PR not close and reopen every time we update from HEAD.

[saschanaz]

was making the PR not close and reopen every time we update from HEAD.

You mean you solved that problem? I wonder how 🧐

[bcoe]

@saschanaz here's the logic that's mostly been working for us for maintaining branches:

https://github.com/googleapis/release-please/blob/master/src/github.ts#L569

[saschanaz]

It's still marked as TODO, so maybe you just haven't recently run into conflicts as you said...

[gr2m]

if you could create a script that reproduces the problem, I'd be happy to look into it myself, too. It sounds like a common-enough use case to create a reusable plugin for

[saschanaz]

It's basically GitHub that closes PRs with zero changes (which happens when updating to HEAD). A repro script will just include updateRef with the target commit HEAD and force:true. You can also do the same in CLI: git reset --hard HEAD && git push -f.

What I need is: an atomic API to 1. do the above and 2. and also createOrUpdateFile().

[kevinbuhmann]

I have a similar use case. Here's my workaround adapted for this scenario:

1. Create a temp branch from master.
2. Create or update the file.
3. Force update the original PR branch with the commit sha from step 2.
4. Delete the temp branch.