Inconsistencies in git-hash-based links between organizations or users repositories

[mont29]

Description

Noted on the newly running Blender gitea forge.

Task #104582 on blender/blender has a git-hash link to the commit #e8805a1a3f which links to https://projects.blender.org/blender/blender/commit/e8805a1a3ff.

However, #e8805a1a3f exists in a different fork, https://projects.blender.org/angavrilov/blender/commit/e8805a1a3ff, and not in blender/blender.

I don't think we can expect gitea to find references to tasks of commits across repositories and forks, but at the very least it should not present a commit in a organization/repo where it does not exist.

Gitea Version

Blender version

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Blender build.

Database

None

[delvh]

I don't understand what you want exactly.
The fact that the links you provided don't show what you intend to say doesn't help either.
It looks like the commit you mentioned was rebased onto blender as well.

Do you want to say that autogenerated links through commit SHAs that don't point to a commit should not be rendered as a link?
Or what exactly is the point this issue is trying to make?

[mont29]

Auto-generation would ideally not work in such case, but this is not my main issue.

I do not expect, when clicking on https://projects.blender.org/blender/blender/commit/e8805a1a3ff, to get a valid page of that commit that presents it as being part of blender/blender repository, when said commit only exists in angavrilov/blender repository.

At the very least, I would expect https://projects.blender.org/blender/blender/commit/e8805a1a3ff to lead to a 404.

[jolheiser]

Ah, I think I see.
Similar to this page, perhaps.

1e80949 (#22892)

I believe we have an open issue for this, I will take a look. I could not find one, but I know we've discussed it before somewhere.

[delvh]

I don't think we can expect gitea to find references to tasks of commits across repositories and forks, but at the very least it should not present a commit in a organization/repo where it does not exist.

If I'm not absolutely mistaken, there isn't even anything we can do about it:
As far as I know, once you open a PR from a fork to a repo, the commits of the base repo branch will be copied to an anonymous branch on the head repo, effectively making it a commit on the parent repo.
This means that we have no way to separate whether a SHA belongs to the repo or not.
If it exists, it belongs to the repo, and otherwise it doesn't.
The only workaround would be to load only SHA commits that are included in the default branch, but that would break so many other things that I don't think we can do it.

[lunny]

I think maybe you mean #18459 ?