Avoid incorrect restore-file on PRs with force pushes

[fregante]

• fixes restore-file occasionally restores the wrong commit #4679

This fixes a GitHub bug related to force pushes:

Note: API v4 repository.pullRequest.baseRefOid falls out out of date after an "update branch" + force push

Repro

1. Create PR modifying a file
2. Modify the same file on main
3. "Update branch" on PR (this updates the baseRefOid)
4. Undo commit and force push
5. Note: baseRefOid does not revert
6. Restore file

I found v3’s compare API to be more reliable, but this needs to be tested further.

Test URLs

• https://github.com/refined-github/sandbox/pull/28/files
• https://github.com/refined-github/sandbox/pull/29/files

[fregante]

Nope… failing for a regular update branch + restore file sequence

• refined-github/sandbox@6ad16fb (#29)

[fregante]

This other feature needs to be implemented first to ensure we're getting the file from the correct "base commit":

• Show base commit in PRs (and not just the base branch) #3863

[yakov116]

This other feature needs to be implemented first to ensure we're getting the file from the correct "base commit":

• Show base commit in PRs (and not just the base branch) #3863

We are doing this, so what else can be the issue?

[fregante]

I'd probably advise against losing time on this.

The issue I found was on GitHub's side. I think the sequence to break it was:

1. Commit A
2. Merge
3. Force push back to commit A

The API reports the new base ("no merge needed") but it's not right.

My suggestion was to implement the other feature first to make these kind of bugs immediately visible.