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

New Issue

GiteaMirror · 2025-11-02T08:54:14-06:00

GiteaMirror commented

2025-11-02 08:54:14 -06:00

Originally created by @parnic on GitHub (Dec 9, 2022).

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:

Create a repo.
1. https://try.gitea.io/parnic-sks/pr-renamed-files-test
Create a file. Make sure it's long enough that a rename + changing contents will still detect the rename.
1. aebe80c2ae
Create a branch from this commit.
1. https://try.gitea.io/parnic-sks/pr-renamed-files-test/src/branch/file-change
Change something in that file and branch.
1. 0bb985908c
Back in the target branch, rename the file and make a small change in it as well.
1. 323c74cae5
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
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

Originally created by @parnic on GitHub (Dec 9, 2022). ### 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 1. 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 1. Create a branch from this commit. 1. https://try.gitea.io/parnic-sks/pr-renamed-files-test/src/branch/file-change 1. Change something in that file and branch. 1. https://try.gitea.io/parnic-sks/pr-renamed-files-test/commit/0bb985908ca24a8fd06972ee8a38a28297957ed8 1. 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 1. 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 1. 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 <img width="881" alt="image" src="https://user-images.githubusercontent.com/888126/206732452-19d73957-5b35-4cb2-b9a4-fd37951bd6de.png"> <img width="474" alt="image" src="https://user-images.githubusercontent.com/888126/206732485-7f331dea-a23b-48c6-a895-15d51f78c415.png"> ### 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

GiteaMirror added the type/bug label 2025-11-02 08:54:14 -06:00

GiteaMirror closed this issue

2025-11-02 08:54:14 -06:00

GiteaMirror commented

2025-11-02 08:54:15 -06:00

@zeripath commented on GitHub (Dec 13, 2022):

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:

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

@zeripath commented on GitHub (Dec 13, 2022): 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

GiteaMirror commented

2025-11-02 08:54:15 -06:00

@zeripath commented on GitHub (Dec 13, 2022):

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.

@zeripath commented on GitHub (Dec 13, 2022): 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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9955