-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CompareAndPullRequestPost() causes internal server error #19527
Comments
The same error, wait for an answer. |
Error persists on
|
When I new pull request (pull from branch A and merge into master), a similar error will appear.
|
When I try to merge master into my branch B, I have the same issue error 500. |
I have fixed it by using the |
I did the same, I was stuck with the GUI |
It would be very helpful if you could create a simple test case to replicate this issue. The likely problem is in TestPatch and is related to the three-way merge here. The error will most likely be originating here: Line 266 in 713bc6c
|
Now the issue is how is one supposed to handle merging when a submodule is turned into a directory or vice versa? |
I have attempted to replicate this locally and on try.gitea.io and am unable to replicate on main. |
@zeripath and others - I am able to reproduce this on try.gitea.io (after running into it on our production server which is using Gitea v1.16.9). Here's what I did:
Is that enough to go off of? I can provide exact git commands if needed, but hopefully they're obvious from the above links. |
Reproduced with same on local install - same thing on 1.16.8 and 1.16.9 Related: when trying to switch from the submodule branch to the directory branch, in order to do the same merge manually (replace the directory with the submodule), I get:
Obviously this can be worked around by starting from a fresh checkout of the directory branch, but maybe the same thing is confusing |
OK adding some logging here, the problem appears to be that:
is left unmerged. AHA I've found the bug |
There is a subtle bug in the code relating to collating the results of `git ls-files -u -z` in `unmergedFiles()`. The code here makes the mistake of assuming that every unmerged file will always have a stage 1 conflict, and this results in conflicts that occur in stage 3 only being dropped. This PR simply adjusts this code to ensure that any empty unmergedFile will always be passed down the channel. The PR also adds a lot of Trace commands to attempt to help find future bugs in this code. Fix go-gitea#19527 Signed-off-by: Andrew Thornton <[email protected]>
) There is a subtle bug in the code relating to collating the results of `git ls-files -u -z` in `unmergedFiles()`. The code here makes the mistake of assuming that every unmerged file will always have a stage 1 conflict, and this results in conflicts that occur in stage 3 only being dropped. This PR simply adjusts this code to ensure that any empty unmergedFile will always be passed down the channel. The PR also adds a lot of Trace commands to attempt to help find future bugs in this code. Fix #19527 Signed-off-by: Andrew Thornton <[email protected]>
…gitea#20528) There is a subtle bug in the code relating to collating the results of `git ls-files -u -z` in `unmergedFiles()`. The code here makes the mistake of assuming that every unmerged file will always have a stage 1 conflict, and this results in conflicts that occur in stage 3 only being dropped. This PR simply adjusts this code to ensure that any empty unmergedFile will always be passed down the channel. The PR also adds a lot of Trace commands to attempt to help find future bugs in this code. Fix go-gitea#19527 Signed-off-by: Andrew Thornton <[email protected]>
) (#20536) There is a subtle bug in the code relating to collating the results of `git ls-files -u -z` in `unmergedFiles()`. The code here makes the mistake of assuming that every unmerged file will always have a stage 1 conflict, and this results in conflicts that occur in stage 3 only being dropped. This PR simply adjusts this code to ensure that any empty unmergedFile will always be passed down the channel. The PR also adds a lot of Trace commands to attempt to help find future bugs in this code. Fix #19527 Signed-off-by: Andrew Thornton <[email protected]> Co-authored-by: zeripath <[email protected]>
This was resolved thanks to @parnic for providing the clear testcase and instructions for reproducing the issue. Once I was able to reproduce the issue using the provided try.gitea.io example I was able to work through the issue in little time. This really highlights the importance of giving us simple reproducing testcases. Thanks once again to @parnic for providing the testcase. |
…gitea#20528) There is a subtle bug in the code relating to collating the results of `git ls-files -u -z` in `unmergedFiles()`. The code here makes the mistake of assuming that every unmerged file will always have a stage 1 conflict, and this results in conflicts that occur in stage 3 only being dropped. This PR simply adjusts this code to ensure that any empty unmergedFile will always be passed down the channel. The PR also adds a lot of Trace commands to attempt to help find future bugs in this code. Fix go-gitea#19527 Signed-off-by: Andrew Thornton <[email protected]>
Description
I have a repository with a vendor folder in the master branch. In separate feature branch, I deleted this folder and replaced it with a git submodule. I then tried to create a Pull Request in the gitea UI, which causes a 500 Internal Server Error:
Error in the logs:
Gitea Version
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
Operating System
Official Gitea Docker image
How are you running Gitea?
Via docker-compose
Database
SQLite
The text was updated successfully, but these errors were encountered: