[Feature Request] Define all templates in same place (config or repo) #6865

New Issue

GiteaMirror · 2025-11-02T07:09:19-06:00

GiteaMirror commented

2025-11-02 07:09:19 -06:00

Originally created by @lonix1 on GitHub (Feb 14, 2021).

There are two types of templates:

template	config location	repo location
labels	$GITEA_CUSTOM/options/label
issue/pr		.gitea/ISSUE_TEMPLATE.md (etc.)

It's not ideal that the label templates are defined in the config, and the issue/pr templates are defined in a repo. Especially since they are related - issue/pr templates refer to labels.

They should both be in the same place - both in config and/or both in a repo.

And if they are defined in both places, the ones in the repo should take precedence.

Originally created by @lonix1 on GitHub (Feb 14, 2021). There are two types of templates: |template|config location|repo location| |---|---|---| |[labels](https://docs.gitea.io/en-us/customizing-gitea/#labels)|$GITEA_CUSTOM/options/label|| |[issue/pr](https://docs.gitea.io/en-us/issue-pull-request-templates/#issue-and-pull-request-templates)||.gitea/ISSUE_TEMPLATE.md (etc.)| It's not ideal that the label templates are defined in the config, and the issue/pr templates are defined in a repo. Especially since they are related - issue/pr templates refer to labels. They should both be in the same place - both in config and/or both in a repo. And if they are defined in both places, the ones in the repo should take precedence.

GiteaMirror added the type/feature type/proposal labels 2025-11-02 07:09:19 -06:00

GiteaMirror commented

2025-11-02 07:09:20 -06:00

@jolheiser commented on GitHub (Feb 14, 2021):

The difference is that label sets are just a default starting point.
A repo may never initialize labels, and once they are initialized they can be changed without ever affecting the default.

PR/issue templates are specific to a repository and can be changed in order to change all future opened PRs/issues.

I agree it would be nice to have a UI for label sets, but I don't think they are directly related to PR/issue templates because they have slightly different uses.

@jolheiser commented on GitHub (Feb 14, 2021): The difference is that label sets are just a default starting point. A repo may never initialize labels, and once they are initialized they can be changed without ever affecting the default. PR/issue templates are specific to a repository and can be changed in order to change all future opened PRs/issues. I agree it would be nice to have a UI for label sets, but I don't think they are directly related to PR/issue templates because they have slightly different uses.

GiteaMirror commented

2025-11-02 07:09:20 -06:00

@lonix1 commented on GitHub (Feb 14, 2021):

I agree with you partly.

One defines labels in config, but an issue template refers to them. So these two things can get out of sync.

Also I found that my templates are roughly the same in all repos, as they match my agile workflow. And I don't want to pollute a code repo with a technical matter (git tooling). Although you are right there is some variance between repos, so I can always add labels via the UI manually.

So I'd prefer to define all templates in config. But I'm sure some will prefer one way and some the other - that's why I said it's best to be flexible.

@lonix1 commented on GitHub (Feb 14, 2021): I agree with you partly. One defines labels in config, but an issue template refers to them. So these two things can get out of sync. Also I found that my templates are roughly the same in all repos, as they match my agile workflow. And I don't want to pollute a code repo with a technical matter (git tooling). Although you are right there is some variance between repos, so I can always add labels via the UI manually. So I'd prefer to define all templates in config. But I'm sure some will prefer one way and some the other - that's why I said it's best to be flexible.

GiteaMirror commented

2025-11-02 07:09:21 -06:00

@zeripath commented on GitHub (Feb 14, 2021):

I think you've missed the point.

One is a pan-gitea thing the other is a per-repo thing.

@zeripath commented on GitHub (Feb 14, 2021): I think you've missed the point. One is a pan-gitea thing the other is a per-repo thing.

GiteaMirror commented

2025-11-02 07:09:21 -06:00

@jolheiser commented on GitHub (Feb 14, 2021):

Is this requesting that labels are manageable via repo-config?

While this would be interesting, I'm not sure how well it would translate to the UI because we would need to ensure they are always in sync, which means changing them from the UI would require a commit to be made to change them in the repo.

@jolheiser commented on GitHub (Feb 14, 2021): Is this requesting that labels are manageable via repo-config? While this would be interesting, I'm not sure how well it would translate to the UI because we would need to ensure they are always in sync, which means changing them from the UI would require a commit to be made to change them in the repo.

GiteaMirror commented

2025-11-02 07:09:22 -06:00

@lunny commented on GitHub (Feb 15, 2021):

There are two differences:

One is for labels only, another is for issues' settings which include labels.
One is for all repositories, another is for only the current repository.

So I think there is no conflict here but I agree that we should consider them in a global view.

@lunny commented on GitHub (Feb 15, 2021): There are two differences: - One is for labels only, another is for issues' settings which include labels. - One is for all repositories, another is for only the current repository. So I think there is no conflict here but I agree that we should consider them in a global view.

GiteaMirror commented

2025-11-02 07:09:22 -06:00

@lonix1 commented on GitHub (Feb 15, 2021):

I think you've missed the point.
One is a pan-gitea thing the other is a per-repo thing.

No I do understand as I explained above.

Why should they apply to different things? What I'm saying is that it makes sense to configure both in the same place. I hope I explained myself properly.

@lonix1 commented on GitHub (Feb 15, 2021): > I think you've missed the point. > One is a pan-gitea thing the other is a per-repo thing. No I do understand as I explained above. Why should they apply to different things? What I'm saying is that it makes sense to configure both in the same place. I hope I explained myself properly.

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