Merged pull request's files changed N/A #3448

New Issue

GiteaMirror · 2025-11-02T05:13:12-06:00

GiteaMirror commented

2025-11-02 05:13:12 -06:00

Originally created by @lunny on GitHub (Jun 10, 2019).

I think this may caused by https://github.com/go-gitea/gitea/pull/6991

@saitho

Originally created by @lunny on GitHub (Jun 10, 2019). ![image](https://user-images.githubusercontent.com/81045/59194248-045f2400-8bbb-11e9-8df3-0d9020b98755.png) I think this may caused by https://github.com/go-gitea/gitea/pull/6991 @saitho

GiteaMirror added the type/bug label 2025-11-02 05:13:12 -06:00

GiteaMirror closed this issue

2025-11-02 05:13:12 -06:00

GiteaMirror commented

2025-11-02 05:13:12 -06:00

@saitho commented on GitHub (Jun 10, 2019):

Was able to confirm that. Will take a look at that. :)

@saitho commented on GitHub (Jun 10, 2019): Was able to confirm that. Will take a look at that. :)

GiteaMirror commented

2025-11-02 05:13:13 -06:00

@saitho commented on GitHub (Jun 10, 2019):

Got it. Will submit PR soon. :)

@saitho commented on GitHub (Jun 10, 2019): Got it. Will submit PR soon. :)

GiteaMirror commented

2025-11-02 05:13:13 -06:00

@shaoran commented on GitHub (Apr 15, 2020):

I'm running Gitea 1.11.3 and on a pull request this started to happen, the File Change link says N/A and my co workers cannot review it. This PR has been fixed a while back so I assume that this is already part of the 1.11.3 release. Is there a way to fix it?

@shaoran commented on GitHub (Apr 15, 2020): I'm running Gitea 1.11.3 and on a pull request this started to happen, the *File Change* link says *N/A* and my co workers cannot review it. This PR has been fixed a while back so I assume that this is already part of the 1.11.3 release. Is there a way to fix it?

GiteaMirror commented

2025-11-02 05:13:13 -06:00

@zeripath commented on GitHub (Apr 15, 2020):

Fixed in 1.11.4

@zeripath commented on GitHub (Apr 15, 2020): Fixed in 1.11.4

GiteaMirror commented

2025-11-02 05:13:13 -06:00

@shaoran commented on GitHub (Apr 15, 2020):

@zeripath I've updated my installation to 1.11.4 and restarted it, but the File Change link on my PR keeps showing N/A. I even closed it and created a new PR from the same commit, the new PR also shows N/A. Other PRs seem not to be affected. Is there a way to fix it via the command line?

@shaoran commented on GitHub (Apr 15, 2020): @zeripath I've updated my installation to 1.11.4 and restarted it, but the *File Change* link on my PR keeps showing *N/A*. I even closed it and created a new PR from the same commit, the new PR also shows *N/A*. Other PRs seem not to be affected. Is there a way to fix it via the command line?

GiteaMirror commented

2025-11-02 05:13:13 -06:00

@zeripath commented on GitHub (Apr 15, 2020):

There's a new command coming in 1.11.5 gitea doctor --run recalculate_merge_bases --fix that should fix it. Or migrating to master should also fix the merge-bases

@zeripath commented on GitHub (Apr 15, 2020): There's a new command coming in 1.11.5 `gitea doctor --run recalculate_merge_bases --fix` that should fix it. Or migrating to master should also fix the merge-bases

GiteaMirror commented

2025-11-02 05:13:13 -06:00

@shaoran commented on GitHub (Apr 15, 2020):

OK, so at the moment I cannot do anything, I'm afraid I'm not going to test the not-released versions, I don't want to have other surprises. But it seems that there is something wrong with my branch. From the same commit I created a new branch, pushed it and created a new PR and the N/A is still there. What could be wrong with my branch that this keeps happening?

@shaoran commented on GitHub (Apr 15, 2020): OK, so at the moment I cannot do anything, I'm afraid I'm not going to test the not-released versions, I don't want to have other surprises. But it seems that there is something wrong with my branch. From the same commit I created a new branch, pushed it and created a new PR and the *N/A* is still there. What could be wrong with my branch that this keeps happening?

GiteaMirror commented

2025-11-02 05:13:14 -06:00

@zeripath commented on GitHub (Apr 15, 2020):

I mean you can just build 1.11.5 and you should be able to simply run the doctor command from that.

gitea doctor --run recalculate_merge_bases shouldn't change anything

However, if you don't want to run code. The correct merge_base for a commit $MERGE_COMMIT_ID from pull $PR_INDEX is:

git merge-base $(git rev-list --parents $MERGE_COMMIT_ID) pull/$PR_INDEX/head

when run from the server gitea-repository $GITEA_REPOSITORIES/owner/reponame.git

@zeripath commented on GitHub (Apr 15, 2020): I mean you can just build 1.11.5 and you should be able to simply run the doctor command from that. `gitea doctor --run recalculate_merge_bases` shouldn't change anything However, if you don't want to run code. The correct merge_base for a commit `$MERGE_COMMIT_ID` from pull `$PR_INDEX` is: `git merge-base $(git rev-list --parents $MERGE_COMMIT_ID) pull/$PR_INDEX/head` when run from the server gitea-repository `$GITEA_REPOSITORIES/owner/reponame.git`

GiteaMirror commented

2025-11-02 05:13:14 -06:00

@shaoran commented on GitHub (Apr 15, 2020):

I executed the line on the bare repo on the server and all I git on stdout is the same SHA1 I passed to git rev-list. But that didn't help, it keeps displaying N/A.

@shaoran commented on GitHub (Apr 15, 2020): I executed the line on the bare repo on the server and all I git on stdout is the same SHA1 I passed to `git rev-list`. But that didn't help, it keeps displaying *N/A*.

GiteaMirror commented

2025-11-02 05:13:14 -06:00

@zeripath commented on GitHub (Apr 15, 2020):

You've run this on the second PR - the one where there is no difference between the head and the base. That's the only way that git merge-base $(git rev-list --parents $MERGE_COMMIT_ID) pull/$PR_INDEX/head can return the same value. I.e. $MERGE_COMMIT_ID == pull/$PR_INDEX/head.

Further just running the command isn't going to change the database you would have to update the PR db entry mergebase with the corrected SHA.

@zeripath commented on GitHub (Apr 15, 2020): You've run this on the second PR - the one where there is no difference between the head and the base. That's the only way that `git merge-base $(git rev-list --parents $MERGE_COMMIT_ID) pull/$PR_INDEX/head` can return the same value. I.e. `$MERGE_COMMIT_ID` == `pull/$PR_INDEX/head`. Further just running the command isn't going to change the database you would have to update the PR db entry mergebase with the corrected SHA.

GiteaMirror commented

2025-11-02 05:13:14 -06:00

@shaoran commented on GitHub (Jul 21, 2020):

Hi,

Once again I have another pull request where suddenly the file changed link is displaying N/A and cannot review it because of it. In the mean time I've upgraded to gitea 1.11.7.

I've executed gitea -c /etc/gitea/app.ini doctor --run recalculate_merge_bases which
generated a long output. The funny thing is that the PR number I was trying to fix (544) does not appear in the output of the doctor command (note, I did not pass the --fix argument).

I also executed on the bare repository on the server

$ git merge-base $(git rev-list --parents pull/544/head) pull/544/head
4cc02d6a40f97f92a36a989adb03ca462d451859

You wrote

Further just running the command isn't going to change the database you would have to update the PR db entry mergebase with the corrected SHA.

how do I do that? Is 4cc02d6 the correct SHA1?

@shaoran commented on GitHub (Jul 21, 2020): Hi, Once again I have another pull request where suddenly the *file changed* link is displaying *N/A* and cannot review it because of it. In the mean time I've upgraded to gitea `1.11.7`. I've executed `gitea -c /etc/gitea/app.ini doctor --run recalculate_merge_bases` which [generated a long output](https://github.com/go-gitea/gitea/files/4952497/doctor.txt). The funny thing is that the PR number I was trying to fix (544) does not appear in the output of the doctor command (note, I did not pass the `--fix` argument). I also executed on the bare repository on the server ```console $ git merge-base $(git rev-list --parents pull/544/head) pull/544/head 4cc02d6a40f97f92a36a989adb03ca462d451859 ``` You wrote > Further just running the command isn't going to change the database you would have to update the PR db entry mergebase with the corrected SHA. how do I do that? Is `4cc02d6` the correct SHA1?

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