Issue Template Uses Incorrect Path For Ref (Commit Instead Of Branch) #9260

Closed
opened 2025-11-02 08:33:28 -06:00 by GiteaMirror · 9 comments
Owner

Originally created by @Deadmano on GitHub (Jul 22, 2022).

Description

When adding an issue from a template, the icon that links to the ref incorrectly wants to reference a commit instead of the branch, despite the branch existing with that same name. See the attached screenshot.

The template.md file contains:

---

name: "New Bug"
about: "Log a new bug!"
title: "Bug: "
ref: "main"
labels:

- bug

---

Expected path: /user/repo/src/branch/main
Actual path: /user/repo/src/commit/main

The actual path, which points to commit does not exist and thus results in a 404.

My understanding is that the link as per the screenshot will take you to the branch/tag as if you manually selected it when creating an issue and picking a branch/tag and the "ref" portion of the template would do exactly that. The documentation on issue templates was vague and doesn't mention what "ref" actually refers to.

Screenshots

Repo_Issue_5

Gitea Version

1.17.0-rc2

Can you reproduce the bug on the Gitea demo site?

No

Operating System

Windows 10

Browser Version

Firefox 102

Originally created by @Deadmano on GitHub (Jul 22, 2022). ### Description When adding an issue from a template, the icon that links to the ref incorrectly wants to reference a commit instead of the branch, despite the branch existing with that same name. See the attached screenshot. The template.md file contains: ```MD --- name: "New Bug" about: "Log a new bug!" title: "Bug: " ref: "main" labels: - bug --- ``` Expected path: `/user/repo/src/branch/main` Actual path: `/user/repo/src/commit/main` The actual path, which points to `commit` does not exist and thus results in a 404. My understanding is that the link as per the screenshot will take you to the branch/tag as if you manually selected it when creating an issue and picking a branch/tag and the "ref" portion of the template would do exactly that. The documentation on issue templates was vague and doesn't mention what "ref" actually refers to. ### Screenshots ![Repo_Issue_5](https://user-images.githubusercontent.com/7104251/180529423-eb3d30d6-0f45-4c3f-9528-1a3782fa800b.PNG) ### Gitea Version 1.17.0-rc2 ### Can you reproduce the bug on the Gitea demo site? No ### Operating System Windows 10 ### Browser Version Firefox 102
GiteaMirror added the topic/uitype/bug labels 2025-11-02 08:33:28 -06:00
Author
Owner

@Deadmano commented on GitHub (Jul 22, 2022):

@6543 & @lunny tagging you both as I believe I saw some things related to changes made in the latest RC that may be relevant? I could have sworn it was working prior to updating to v1.17.0-rc2, link pointing to the actual branch. I went back to 1.17.0+rc1-34-g4c1f4ee84 and the issue now still persists. Any feedback would be greatly appreciated!

@Deadmano commented on GitHub (Jul 22, 2022): @6543 & @lunny tagging you both as I believe I saw some things related to changes made in the latest RC that may be relevant? I could have sworn it was working prior to updating to `v1.17.0-rc2`, link pointing to the actual _branch_. I went back to `1.17.0+rc1-34-g4c1f4ee84` and the issue now still persists. Any feedback would be greatly appreciated!
Author
Owner

@zeripath commented on GitHub (Jul 22, 2022):

Have you tried?

---

name: "New Bug"
about: "Log a new bug!"
title: "Bug: "
ref: "refs/heads/main"
labels:

- bug

---
@zeripath commented on GitHub (Jul 22, 2022): Have you tried? ```yaml --- name: "New Bug" about: "Log a new bug!" title: "Bug: " ref: "refs/heads/main" labels: - bug --- ```
Author
Owner

@zeripath commented on GitHub (Jul 22, 2022):

If this represents a change in behaviour from 1.16 I think we should change:

599ae09a94/modules/context/repo.go (L1081-L1088)

to prepend the refs/heads/ to the Ref if it does not match a SHA or does not already start with refs/

@zeripath commented on GitHub (Jul 22, 2022): If this represents a change in behaviour from 1.16 I think we should change: https://github.com/go-gitea/gitea/blob/599ae09a94e40f9ef567aa2ec7486f68a64a3384/modules/context/repo.go#L1081-L1088 to prepend the `refs/heads/` to the `Ref` if it does not match a SHA or does not already start with `refs/`
Author
Owner

@Deadmano commented on GitHub (Jul 22, 2022):

@zeripath that did it; you are a wonderful soul! Now what I'd love to know is why it was working prior, and updating to the latest RC seemingly broke it? I tried multiple repos, initialised both via CLI, GUI, and via the Web Interface, and it made no change to the template issue.

Is there something specific I'm meant to do when upgrading from an older install? I just shut down the instance, replaced the previous executable with the newer one, and then fired it up again.

Perhaps the documentation can be updated to explain how Ref works? I had no idea it takes a literal Git ref since the wording in the example makes it seem as if it'd point to a default main branch.

Would it then be refs/tags/{version} for tags?

@Deadmano commented on GitHub (Jul 22, 2022): @zeripath that did it; you are a wonderful soul! Now what I'd love to know is why it was working prior, and updating to the latest RC seemingly broke it? I tried multiple repos, initialised both via CLI, GUI, and via the Web Interface, and it made no change to the template issue. Is there something specific I'm meant to do when upgrading from an older install? I just shut down the instance, replaced the previous executable with the newer one, and then fired it up again. Perhaps the [documentation](https://docs.gitea.io/en-us/issue-pull-request-templates/#issue-template-directory) can be updated to explain how Ref works? I had no idea it takes a literal Git ref since the wording in the example makes it seem as if it'd point to a default `main` branch. Would it then be `refs/tags/{version}` for tags?
Author
Owner

@zeripath commented on GitHub (Jul 22, 2022):

Was it definitely doing this other behaviour in 1.16? If so that is likely to mean that it's an unintended change of behaviour and we should implement the changes I've suggested above

@zeripath commented on GitHub (Jul 22, 2022): Was it definitely doing this other behaviour in 1.16? If so that is likely to mean that it's an unintended change of behaviour and we should implement the changes I've suggested above
Author
Owner

@Deadmano commented on GitHub (Jul 22, 2022):

It was working fine under 1.17.0+rc1-34-g4c1f4ee84 which I installed the binary gitea-1.17-windows-4.0-amd64.exe from the 1.17 downloads page. This is the first release I ever downloaded and started with.

I tried upgrading to v1.17.0-rc2 from GitHub directly using the gitea-1.17.0-rc2-windows-4.0-amd64.exe file which is when I noticed this starting to happen with my templates.

@Deadmano commented on GitHub (Jul 22, 2022): It was working fine under `1.17.0+rc1-34-g4c1f4ee84` which I installed the binary [gitea-1.17-windows-4.0-amd64.exe](https://dl.gitea.io/gitea/1.17/gitea-1.17-windows-4.0-amd64.exe) from the [1.17 downloads page](https://dl.gitea.io/gitea/1.17). This is the first release I ever downloaded and started with. I tried upgrading to [v1.17.0-rc2](https://github.com/go-gitea/gitea/releases/tag/v1.17.0-rc2) from GitHub directly using the [gitea-1.17.0-rc2-windows-4.0-amd64.exe](https://github.com/go-gitea/gitea/releases/download/v1.17.0-rc2/gitea-1.17.0-rc2-windows-4.0-amd64.exe) file which is when I noticed this starting to happen with my templates.
Author
Owner

@Deadmano commented on GitHub (Jul 22, 2022):

Also I noticed some strange behaviour with the pathing in the URLs.

Take for example these two paths:

/user/repo/src/brach/
/user/repo/src/commit/

If you were to enter them as per above they get malformed into:

/user/repo/src/branch/branch/main/branch
/user/repo/src/commit/branch/main/commit

Is this behaviour intended and/or related?

@Deadmano commented on GitHub (Jul 22, 2022): Also I noticed some strange behaviour with the pathing in the URLs. Take for example these two paths: ``` /user/repo/src/brach/ /user/repo/src/commit/ ``` If you were to enter them as per above they get malformed into: ``` /user/repo/src/branch/branch/main/branch /user/repo/src/commit/branch/main/commit ``` Is this behaviour intended and/or related?
Author
Owner

@zeripath commented on GitHub (Jul 22, 2022):

Take for example these two paths:

What do you mean "path"? Do you mean "URL" as in:

http://gitea/user/repo/src/<some-path-that-is-not-a-branch> 

is transformed to:

http://gitea/user/repo/src/branch/master/<some-path-that-is-not-a-branch> 

If so then this is very much longstanding behaviour which has been present since before I have been submitting PRs to gitea and likely dates back to Gogs and relates to a legacy way of pointing to src files.

(Likely this should have been removed at least 3 years ago as it was legacy at that point.)

@zeripath commented on GitHub (Jul 22, 2022): >Take for example these two paths: What do you mean "path"? Do you mean "URL" as in: http://gitea/user/repo/src/<some-path-that-is-not-a-branch> is transformed to: http://gitea/user/repo/src/branch/master/<some-path-that-is-not-a-branch> If so then this is very much longstanding behaviour which has been present since before I have been submitting PRs to gitea and likely dates back to Gogs and relates to a legacy way of pointing to src files. (Likely this should have been removed at least 3 years ago as it was legacy at that point.)
Author
Owner

@zeripath commented on GitHub (Jul 22, 2022):

OK Issue templates was in 1.16.0 so there has been an unintended change here and we should change the code above to prepend the refs/heads/ if it doesn't start with refs/.

An alternative option is to try to detect which ref this could be referring to as I suspect that people might actually want tags etc to be detected nicely.

I'm not certain.

@zeripath commented on GitHub (Jul 22, 2022): OK Issue templates was in 1.16.0 so there has been an unintended change here and we should change the code above to prepend the `refs/heads/` if it doesn't start with `refs/`. An alternative option is to try to detect which ref this could be referring to as I suspect that people might actually want tags etc to be detected nicely. I'm not certain.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#9260