Incorrect branch name given when browsing commit

[CirnoT]

Related to #11847 (review)

Given commit 7c75262e6f12881b1c700556460654616d992384 from few years ago and dead branch permissions for which exists closed PR #3.

git name-rev --exclude "refs/tags/*" --name-only --no-undefined 7c75262e6f12881b1c700556460654616d992384
pull/3/head~2602^2~3

git name-rev --refs "refs/heads/*" --name-only --no-undefined 7c75262e6f12881b1c700556460654616d992384
permissions~2603^2~3

I would expect that when browsing commit 7c75262e6f12881b1c700556460654616d992384 I am shown master as branch, not pull/3/head or permissions.

GetBranchName should behave something like this:

• if commit exists in default branch, use it
• otherwise select closest branch name

where closest branch is either newest branch for which HEAD there isn't entry in pull or otherwise branch that is closest (with fewest commits between HEAD and commit) if there is no other non-PR branch that contains commit.

[CirnoT]

Another case:

• with master on commit c
• PR #1 adds commit x after a and is merged-squashed as commit b
• PR #2 adds commit y after b and is merged-squashed as commit c
• browse commit a, the branch Gitea shows is pull/1/head, because that reference is closer to a than master by one commit.

[CirnoT]

Might be over-thinking this however given how GH behaves similarly (kind of):
1cd6233
https://try.gitea.io/mika/gitea/commit/1cd6233cef9f7fcefb200f82f9d0990e45684aa5

git name-rev --refs "refs/heads/*" --name-only --no-undefined 1cd6233cef9f7fcefb200f82f9d0990e45684aa5
lunny/display_deleted_branch2~45

So maybe just using --refs "refs/heads/*" is enough? What do you all think?

[zeripath]

Another option is to use git for-each-ref --points-to=... to get all the refs that point to the commit and display them all (sorted in some way)

[CirnoT]

We could definitely display tags; unsure about whether we should display all branches.

Is there any Fomantic element that would take care of hiding/revealing items within it automagically (ie. based on customized amount of children)?

[zeripath]

Not that I'm aware of.

If you find one we can handle co-authors properly.

I'm happy with losing the pulls and fixing the refs properly at some other point.

[CirnoT]

We could still fetch pulls separately and display link to PR like GitHub does: ${branch} (${prLink})

[zeripath]

The trouble is all of these assumptions are that only one branch, pull or tag points to a commit when in reality multiple things often to point to the same commit

[CirnoT]

Yes.

In case of branch, it's simple matter to display closest one, seems that GH does it that way too, so that's a + since users are already used to it.

For tags, GH shows all tags that contain the commit but hide them behind reveal anchor, only showing newest one by default. Note however that tag is shown only if there is at least one tag difference between - that is right now cefbf73 doesn't show any tag, but once v1.14-dev is created it will be replaced by newest one, say v1.13-rc1.

For PRs it is becoming a rather lengthy ordeal - ideally we'd fetch that data from database, as with squashing we really have no way to find out which pull ref the commit comes from.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[CirnoT]

bad bot

[wxiaoguang]

The code has changed a lot.

Didn't see the "incorrect branch" on /owner/repo/commit/..... page: