Merged pull request's files changed N/A

[lunny]

I think this may caused by #6991

@saitho

[saitho]

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

[saitho]

Got it. Will submit PR soon. :)

[shaoran]

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?

[zeripath]

Fixed in 1.11.4

[shaoran]

@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?

[zeripath]

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

[shaoran]

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?

[zeripath]

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

[shaoran]

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.

[zeripath]

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.

[shaoran]

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?