Subtree (or otherwise) (mention)/event filtering #11810

New Issue

GiteaMirror · 2025-11-02T09:48:29-06:00

GiteaMirror commented

2025-11-02 09:48:29 -06:00

Originally created by @deliciouslytyped on GitHub (Oct 7, 2023).

Feature Description

I have a repository that contains several git subtrees [1], vendoring projects we have local patches to. When (initially) pushing my repository with these subtrees contained within, this triggers Gitea's notification/mentions mechanism to (as expected) tag, for example, issues mentioned with the #somenumber syntax, even though a lot of those mentions come from the subtrees and are actually meant to mention issues in the upstream projects repositories.

Specifically, this is the case if subtree is used with unsquashed upstream (I'm not sure this is at all how this works) commits (since this way, all commits are in the history). My understanding is there is a squash feature in subtree but I've never used it.

For example:

myproject/vendor/someupstream is a subtree
pushing my repository to my gitea myuser/myproject project also sends the commits that are in myproject due to someupstream (if they are used unsquashed)
if 123somecommithash123 pertaining to someupstream has "fixed #123456789" in it's commit message, this will show a mention in the myproject issue #123456789, which can lead to a lot of extraneous mentions due to the extensive histories and mentions of the included subtree, which is noisy and undesirable.

I'm not sure how a feature to fix this would look in the ideal case, but some ability to filter event triggering would be nice.
You can't just completely filter things pertaining to subtrees because we would like to have mentions from our own patches to upstream.

The only issue I found that seemed even minimally related to this is https://github.com/go-gitea/gitea/issues/14786 .

[1] (For lack of any better ideas, see these if you're unfamiliar with subtrees;

Screenshots:

The mention on a project issue:
The commit view from clicking the mention is below:
(It seems subtree commits may have a special structure or something? It's not visible in this view that that this ends up in a subdirectory of the project; these are probably the exact upstream commits and the subtree merge is what makes them show up in the right place in the repo. Perhaps this may be worth some kind of another UI issue.)
The subtree merge commit:
The commit graph in gitea, the red branch is the upstream repo, the green is my repo

Screenshots

No response

Originally created by @deliciouslytyped on GitHub (Oct 7, 2023). ### Feature Description I have a repository that contains several git subtrees [1], vendoring projects we have local patches to. When (initially) pushing my repository with these subtrees contained within, this triggers Gitea's notification/mentions mechanism to (as expected) tag, for example, issues mentioned with the `#somenumber` syntax, even though a lot of those mentions come from the subtrees and are actually meant to mention issues in the upstream projects repositories. Specifically, this is the case if subtree is used with unsquashed upstream (I'm not sure this is at all how this works) commits (since this way, all commits are in the history). My understanding is there is a squash feature in subtree but I've never used it. For example: - myproject/vendor/someupstream is a subtree - pushing my repository to my gitea myuser/myproject project also sends the commits that are in myproject due to someupstream (if they are used unsquashed) - if 123somecommithash123 pertaining to someupstream has "fixed #123456789" in it's commit message, this will show a mention in the myproject issue #123456789, which can lead to a lot of extraneous mentions due to the extensive histories and mentions of the included subtree, which is noisy and undesirable. I'm not sure how a feature to fix this would look in the ideal case, but some ability to filter event triggering would be nice. You can't just completely filter things pertaining to subtrees because we would like to have mentions from our own patches to upstream. The only issue I found that seemed even minimally related to this is https://github.com/go-gitea/gitea/issues/14786 . [1] (For lack of any better ideas, see these if you're unfamiliar with subtrees; - https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_subtree_merge - https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt - https://stackoverflow.com/questions/11741249/what-is-the-difference-between-git-subtree-merge-and-git-subtree ) # Screenshots: - The mention on a project issue: ![image](https://github.com/go-gitea/gitea/assets/47436522/6d3d90c5-cc23-4e56-bd53-916896f3e85d) - The commit view from clicking the mention is below: (It seems subtree commits may have a special structure or something? It's not visible in this view that that this ends up in a subdirectory of the project; these are probably the exact upstream commits and the subtree merge is what makes them show up in the right place in the repo. Perhaps this may be worth some kind of another UI issue.) ![image](https://github.com/go-gitea/gitea/assets/47436522/1775a738-2fe4-4dc9-9583-469801e45dbe) - The subtree merge commit: ![image](https://github.com/go-gitea/gitea/assets/47436522/648cf621-955c-438d-89af-a320091b637d) - The commit graph in gitea, the red branch is the upstream repo, the green is my repo ![image](https://github.com/go-gitea/gitea/assets/47436522/fe77830f-8e2c-42f4-8235-c3a2e4bbc79c) ### Screenshots _No response_

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