Merge request conflicts remaining after manual resolution, counters showing "N/A" #11186

New Issue

GiteaMirror · 2025-11-02T09:30:12-06:00

GiteaMirror commented

2025-11-02 09:30:12 -06:00

Originally created by @mpeter50 on GitHub (Jul 8, 2023).

Description

I have a pull request that had a merge conflict, which I resolved manually earlier today, and pushed the changes to Gitea, but Gitea still thinks that there is a merge conflict. Other software I use (Git Extensions and my IDE) show that the merge was successful, and I see the merge commit on Gitea too. The Gitea Commit Grapgh also confirms that the branches were merged in a merge commit.

Other than that, the counter on the "Commits" and "Files Changed" tabs near the top of the merge request page show "N/A" instead of the number of commits and files changed. I think it ended up this way after I uploaded the merge commit.
The tabs are also not clickable, but if I forcibly open them by loading them by URL (e.g. https://gitea.rpi.lan/MPeter/twitch-archiver/pulls/39/commits), then the Commits tab shows "These branches are equal. (master)", and the Files Changed tab shows "Diff Content Not Available".
Opening the Commits tab resulted in an "500 Internal Server Error" being printed to the log but only once, navigating elsewhere and then back to this by URL does not log that error again, and opening the Files Changed tab did not log an error at all.
I don't have logs from when the commit was updated. Forgot to save them before updating Gitea..

Right now I'm running Gitea 1.19.4, but I have recently updated from 1.19.0, which was in use when the merge commit was uploaded.

#24729 may be related, however I didn't even know there should be an option to mark it as manually merged.

Gitea Version

1.19.4

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/mpeter50/ae538e25ae60fa5b3aedeeb110c1b967

Screenshots

Top of PR page	Bottom of PR page

Commits tab	Files Changed tab

Git Version

2.38.5

Operating System

Debian 10

How are you running Gitea?

I have built Gitea from the original sources, using the Docker.rootless Dockerfile in the repo root, at the v1.19.4 git tag, on an x86_64 OS for ARM.

I run Gitea with Docker.

Database

MySQL

Originally created by @mpeter50 on GitHub (Jul 8, 2023). ### Description I have a pull request that had a merge conflict, which I resolved manually earlier today, and pushed the changes to Gitea, but Gitea still thinks that there is a merge conflict. Other software I use (Git Extensions and my IDE) show that the merge was successful, and I see the merge commit on Gitea too. The Gitea Commit Grapgh also confirms that the branches were merged in a merge commit. Other than that, the counter on the "Commits" and "Files Changed" tabs near the top of the merge request page show "N/A" instead of the number of commits and files changed. I think it ended up this way after I uploaded the merge commit. The tabs are also not clickable, but if I forcibly open them by loading them by URL (e.g. https://gitea.rpi.lan/MPeter/twitch-archiver/pulls/39/commits), then the Commits tab shows "These branches are equal. (master)", and the Files Changed tab shows "Diff Content Not Available". Opening the Commits tab resulted in an "500 Internal Server Error" being printed to the log but only once, navigating elsewhere and then back to this by URL does not log that error again, and opening the Files Changed tab did not log an error at all. I don't have logs from when the commit was updated. Forgot to save them before updating Gitea.. Right now I'm running Gitea 1.19.4, but I have recently updated from 1.19.0, which was in use when the merge commit was uploaded. #24729 may be related, however I didn't even know there should be an option to mark it as manually merged. ### Gitea Version 1.19.4 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist https://gist.github.com/mpeter50/ae538e25ae60fa5b3aedeeb110c1b967 ### Screenshots |Top of PR page|Bottom of PR page| |-|-| |![image](https://github.com/go-gitea/gitea/assets/83356418/76839903-daaf-40b5-99e3-ae0a66fd2440)|![image](https://github.com/go-gitea/gitea/assets/83356418/68061bdc-d6fc-4b33-9530-053fb28c2b2a)| |Commits tab|Files Changed tab| |-|-| |![image](https://github.com/go-gitea/gitea/assets/83356418/523261b4-295b-4cd0-9ba1-f7f01540e551)|![image](https://github.com/go-gitea/gitea/assets/83356418/96426d67-ea3c-4d1a-b1a7-ce50f1bb5c4a)| ### Git Version 2.38.5 ### Operating System Debian 10 ### How are you running Gitea? I have built Gitea from the original sources, using the Docker.rootless Dockerfile in the repo root, at the v1.19.4 git tag, on an x86_64 OS for ARM. I run Gitea with Docker. ### Database MySQL

GiteaMirror added the type/bug label 2025-11-02 09:30:12 -06:00

GiteaMirror commented

2025-11-02 09:30:13 -06:00

@mpeter50 commented on GitHub (Jul 8, 2023):

#283 looks even more similar: same situation, similar result, even the mentioned counters are the same.
But, in my case Gitea does not seem to want to rerun conflict checking. The screenshots I have taken are all from just a few minutes before sending in the issue.

@mpeter50 commented on GitHub (Jul 8, 2023): #283 looks even more similar: same situation, similar result, even the mentioned counters are the same. But, in my case Gitea does not seem to want to rerun conflict checking. The screenshots I have taken are all from just a few minutes before sending in the issue.

GiteaMirror commented

2025-11-02 09:30:14 -06:00

@mpeter50 commented on GitHub (Jul 8, 2023):

Oh, it turns out at first they had the same error message as me, but closed and reopened the PR to get that other state.

@mpeter50 commented on GitHub (Jul 8, 2023): Oh, [it turns out](283#issuecomment-263811931) at first they had the same error message as me, but closed and reopened the PR to get that other state.

GiteaMirror commented

2025-11-02 09:30:14 -06:00

@mpeter50 commented on GitHub (Jul 15, 2023):

The same thing happens when Gitea could do the merge automatically, but I forget about it and do it locally, and push the merge commit. The problem may be that Gitea does not realize that the branch has been merged.

@mpeter50 commented on GitHub (Jul 15, 2023): The same thing happens when Gitea could do the merge automatically, but I forget about it and do it locally, and push the merge commit. The problem may be that Gitea does not realize that the branch has been merged.

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#11186