Server error 500 creating a PR against a branch with changes to a file that has been renamed in the target branch

[parnic]

Description

Creating a PR against a branch with changes to a file that has since been renamed in the target branch will cause an error 500 and inability to open the PR. When this happens, the server logs only say

2022/12/09 14:35:19 ...ers/web/repo/pull.go:1244:CompareAndPullRequestPost() [E] NewPullRequest: git apply --check: exit status 1

so it's difficult to understand what to do to work around it. The appropriate workaround is to update the source branch with latest from the target branch before opening the PR.

Specific repro steps:

1. Create a repo.
   1. https://try.gitea.io/parnic-sks/pr-renamed-files-test
2. Create a file. Make sure it's long enough that a rename + changing contents will still detect the rename.
   1. https://try.gitea.io/parnic-sks/pr-renamed-files-test/commit/aebe80c2ae9dd290c8359cb4e6c4df45ed23fc19
3. Create a branch from this commit.
   1. https://try.gitea.io/parnic-sks/pr-renamed-files-test/src/branch/file-change
4. Change something in that file and branch.
   1. https://try.gitea.io/parnic-sks/pr-renamed-files-test/commit/0bb985908ca24a8fd06972ee8a38a28297957ed8
5. Back in the target branch, rename the file and make a small change in it as well.
   1. https://try.gitea.io/parnic-sks/pr-renamed-files-test/commit/323c74cae5fda0b276daad71df0905503af7d331
6. Attempt to open a PR from the outdated source branch to the target branch with the renamed + changed file.
   1. https://try.gitea.io/parnic-sks/pr-renamed-files-test/compare/main...file-change
7. The diff on this page looks fine, but trying to actually create the PR results in a 500 error on client and "git apply --check" error on server.

I can supply specific git commands needed for each step if it's helpful, but hopefully they're obvious from the given links.

Locally running the git apply command that the server is presumably running results in the following message (that doesn't show up on the server):

> git show 0bb985908ca24a8fd06972ee8a38a28297957ed8 | git apply --check
error: 1.txt: No such file or directory

which is what clued me into the problem.

Gitea Version

1.17.3, can also repro on try.gitea.io at v1.19.0+dev-171-g2779d47ad

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

See description

Screenshots

Git Version

2.37.3 on the Gitea v1.17.3 instance, whatever version is on try.gitea.io

Operating System

Ubuntu 20.04.5 aarch64

How are you running Gitea?

Built myself with a few modifications from v1.17.3 (mostly cherry-picking things from the future).

https://try.gitea.io however that's built

Database

PostgreSQL

[zeripath]

OK, that's a new error from git apply.

I'm actually not sure if we should keep the git apply path around anymore - I think the git read-tree path might be covering all of our bases and I only kept the old path around because it was new.

So, I reckon we should:

1. use the provided reproducer information to create a test-case.
2. detect the error as above - which would be simple and backport that.
3. Disable the git-apply route but add a config value to allow fallback - which can be removed in Gitea 1.20

[zeripath]

I've put up a PR to just add the handling for "No such file or directory", I'll look at creating the testcase this evening.