Server error 500 creating a PR against a branch with changes to a file that has been renamed in the target branch #22083
Comments
|
OK, that's a new error from I'm actually not sure if we should keep the So, I reckon we should:
|
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
Dec 13, 2022
Moved files in a patch will result in git apply returning:
```
error: {filename}: No such file or directory
```
This wasn't handled by the git apply patch code. This PR adds handling
for this.
Fix go-gitea#22083
Signed-off-by: Andrew Thornton <art27@cantab.net>
|
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
added a commit
to zeripath/gitea
that referenced
this issue
Dec 14, 2022
For a long time Gitea has tested PR patches using a git apply --check method and in fact prior to the introduction of a read-tree assisted three-way merge in go-gitea#18004, this was the only way of checking patches. Since go-gitea#18004, the git apply --check method has been a fallback method, only used when the read-tree method has detected a conflict. The read-tree assisted three-way merge method is much faster and less resource intensive method of detecting conflicts. go-gitea#18004 kept the git apply method around because it was thought possible that this fallback might be able to rectify conflicts that the read-tree three-way merge detected. I am not certain if this could ever be the case. Given the uncertainty here and the now relative stability of the read-tree method - this PR makes using this fallback optional and disables it by default. The hope is that users will not mention any significant difference in conflict detection and we will be able to remove the git apply fallback in future, and/or improve the read-tree three-way merge method to catch any conflicts that git apply method might have been incorrectly detecting. (See https://github.com/go-gitea/gitea/issues/22083\#issuecomment-1347961737) Ref go-gitea#22083 Signed-off-by: Andrew Thornton <art27@cantab.net>
lunny
pushed a commit
that referenced
this issue
Dec 14, 2022
Moved files in a patch will result in git apply returning:
```
error: {filename}: No such file or directory
```
This wasn't handled by the git apply patch code. This PR adds handling
for this.
Fix #22083
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
Dec 14, 2022
Backport go-gitea#22118 Moved files in a patch will result in git apply returning: ``` error: {filename}: No such file or directory ``` This wasn't handled by the git apply patch code. This PR adds handling for this. Fix go-gitea#22083 Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
Dec 14, 2022
Backport go-gitea#22118 Moved files in a patch will result in git apply returning: ``` error: {filename}: No such file or directory ``` This wasn't handled by the git apply patch code. This PR adds handling for this. Fix go-gitea#22083 Signed-off-by: Andrew Thornton <art27@cantab.net>
lunny
pushed a commit
that referenced
this issue
Dec 15, 2022
Backport #22118 Moved files in a patch will result in git apply returning: ``` error: {filename}: No such file or directory ``` This wasn't handled by the git apply patch code. This PR adds handling for this. Fix #22083 Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
techknowlogick
pushed a commit
that referenced
this issue
Dec 15, 2022
Backport #22118 Moved files in a patch will result in git apply returning: ``` error: {filename}: No such file or directory ``` This wasn't handled by the git apply patch code. This PR adds handling for this. Fix #22083 Signed-off-by: Andrew Thornton <art27@cantab.net> Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
lunny
added a commit
that referenced
this issue
Dec 19, 2022
For a long time Gitea has tested PR patches using a git apply --check method, and in fact prior to the introduction of a read-tree assisted three-way merge in #18004, this was the only way of checking patches. Since #18004, the git apply --check method has been a fallback method, only used when the read-tree three-way merge method has detected a conflict. The read-tree assisted three-way merge method is much faster and less resource intensive method of detecting conflicts. #18004 kept the git apply method around because it was thought possible that this fallback might be able to rectify conflicts that the read-tree three-way merge detected. I am not certain if this could ever be the case. Given the uncertainty here and the now relative stability of the read-tree method - this PR makes using this fallback optional and disables it by default. The hope is that users will not notice any significant difference in conflict detection and we will be able to remove the git apply fallback in future, and/or improve the read-tree three-way merge method to catch any conflicts that git apply method might have been able to fix. An additional benefit is that patch checking should be significantly less resource intensive and much quicker. (See https://github.com/go-gitea/gitea/issues/22083\#issuecomment-1347961737) Ref #22083 Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
zeripath
added a commit
to zeripath/gitea
that referenced
this issue
Dec 19, 2022
Backport go-gitea#22130 For a long time Gitea has tested PR patches using a git apply --check method, and in fact prior to the introduction of a read-tree assisted three-way merge in go-gitea#18004, this was the only way of checking patches. Since go-gitea#18004, the git apply --check method has been a fallback method, only used when the read-tree three-way merge method has detected a conflict. The read-tree assisted three-way merge method is much faster and less resource intensive method of detecting conflicts. go-gitea#18004 kept the git apply method around because it was thought possible that this fallback might be able to rectify conflicts that the read-tree three-way merge detected. I am not certain if this could ever be the case. Given the uncertainty here and the now relative stability of the read-tree method - this PR makes using this fallback optional but enables it by default. A `log.Critical` has been added which will alert if the `git apply --check` method was successful at checking a PR that `read-tree` failed on. The hope is that none of these log.Critical messages will be found and there will be no significant difference in conflict detection. Thus we will be able to remove the git apply fallback in future, and/or improve the read-tree three-way merge method to catch any conflicts that git apply method might have been able to fix. An additional benefit for anyone who disables the check method is that patch checking should be significantly less resource intensive and much quicker. (See https://github.com/go-gitea/gitea/issues/22083\#issuecomment-1347961737) Ref go-gitea#22083 Signed-off-by: Andrew Thornton <art27@cantab.net>
KN4CK3R
added a commit
that referenced
this issue
Dec 22, 2022
) Backport #22130 For a long time Gitea has tested PR patches using a git apply --check method, and in fact prior to the introduction of a read-tree assisted three-way merge in #18004, this was the only way of checking patches. Since #18004, the git apply --check method has been a fallback method, only used when the read-tree three-way merge method has detected a conflict. The read-tree assisted three-way merge method is much faster and less resource intensive method of detecting conflicts. #18004 kept the git apply method around because it was thought possible that this fallback might be able to rectify conflicts that the read-tree three-way merge detected. I am not certain if this could ever be the case. Given the uncertainty here and the now relative stability of the read-tree method - this PR makes using this fallback optional but enables it by default. A `log.Critical` has been added which will alert if the `git apply --check` method was successful at checking a PR that `read-tree` failed on. The hope is that none of these log.Critical messages will be found and there will be no significant difference in conflict detection. Thus we will be able to remove the git apply fallback in future, and/or improve the read-tree three-way merge method to catch any conflicts that git apply method might have been able to fix. An additional benefit for anyone who disables the check method is that patch checking should be significantly less resource intensive and much quicker. (See https://github.com/go-gitea/gitea/issues/22083\#issuecomment-1347961737) Ref #22083 Signed-off-by: Andrew Thornton <art27@cantab.net> <!-- Please check the following: 1. Make sure you are targeting the `main` branch, pull requests on release branches are only allowed for bug fixes. 2. Read contributing guidelines: https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md 3. Describe what your pull request does and which issue you're targeting (if any) --> Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
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:
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 applycommand that the server is presumably running results in the following message (that doesn't show up on the server):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
The text was updated successfully, but these errors were encountered: