github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Gitea incorrectly auto-closes issue even though referenced branch has not been merged yet #14268

New Issue
Closed
opened 2025-11-02 11:08:03 -06:00 by GiteaMirror · 13 comments
GiteaMirror commented 2025-11-02 11:08:03 -06:00
Owner
Copy Link

Originally created by @reimer-atb on GitHub (Mar 18, 2025).

Description

Gitea incorrectly auto-closes an issue if you force-push to a PR referencing that issue, even though the PR is still open and not merged into the main branch.

Steps to reproduce

  1. Create a repo with a single file README.md.

  2. Create issue "A" in that repo

  3. Create a new branch "<issue_number>-A" for the issue, add some changes to README.md, commit them with message "closes #<issue_number>" to enable auto-close when the branch is merged, and push it

  4. Create a pull request based on branch "<issue_number>-A" above

  5. Link the issue to the pull request branch "<issue_number>-A"

    Image

  6. Create a second branch "B" based on "main", add a change to README.md that conflicts with a change in branch "<issue_number>-A", and push it

  7. Create a pull request for the second branch "B", and merge it using "Rebase
    then fast-forward" and selecting "Delete Branch "B""

  8. Pull the updated "main" branch locally, switch to branch "<issue_number>-A", and run git rebase main

  9. Resolve the conflict in README.md keeping both changes, and run git add README.md, then git rebase --continue

  10. Run git push --force-with-lease

Result

Issue "A" is auto-closed (see https://demo.gitea.com/reimer-atb/test/issues/1)

Image

even though the PR is still open and branch "<issue_number>-A" has not been merged into "main" (see https://demo.gitea.com/reimer-atb/test/pulls/2).

Image

Expected result

Issue "A" should remain "open". It should only be auto-closed when the PR is merged into "main".

Gitea Version

1.23.5 and 1.24.0+dev-424-g403775e74e

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.49.0

Operating System

No response

How are you running Gitea?

I used demo.gitea.com. It also happens on our gitea instance (version 1.23.5). But I don't manage that and don't know what it runs on.

Database

None

Originally created by @reimer-atb on GitHub (Mar 18, 2025). ### Description Gitea incorrectly auto-closes an issue if you force-push to a PR referencing that issue, even though the PR is still open and not merged into the main branch. ### Steps to reproduce 1. Create a repo with a single file `README.md`. 1. Create issue "A" in that repo 1. Create a new branch "<issue_number>-A" for the issue, add some changes to `README.md`, commit them with message "closes #<issue_number>" to enable auto-close when the branch is merged, and push it 1. Create a pull request based on branch "<issue_number>-A" above 1. Link the issue to the pull request branch "<issue_number>-A" ![Image](https://github.com/user-attachments/assets/6df9fba0-053c-46ea-b5d5-7defbe0641f1) 1. Create a **second** branch "B" based on "main", add a change to `README.md` that **conflicts** with a change in branch "<issue_number>-A", and push it 1. Create a pull request for the second branch "B", and merge it using "Rebase then fast-forward" and selecting "Delete Branch "B"" 1. Pull the updated "main" branch locally, switch to branch "<issue_number>-A", and run `git rebase main` 1. Resolve the conflict in `README.md` keeping both changes, and run `git add README.md`, then `git rebase --continue` 1. Run `git push --force-with-lease` ### Result Issue "A" is auto-closed (see https://demo.gitea.com/reimer-atb/test/issues/1) ![Image](https://github.com/user-attachments/assets/277af2b9-daf3-4d0c-bdef-b363d5f9c7a9) even though the PR is still open and branch "<issue_number>-A" has not been merged into "main" (see https://demo.gitea.com/reimer-atb/test/pulls/2). ![Image](https://github.com/user-attachments/assets/e2d4f270-fd58-4397-9a09-1dac69d741fe) ### Expected result Issue "A" should remain "open". It should only be auto-closed when the PR is merged into "main". ### Gitea Version 1.23.5 and 1.24.0+dev-424-g403775e74e ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.49.0 ### Operating System _No response_ ### How are you running Gitea? I used demo.gitea.com. It also happens on our gitea instance (version 1.23.5). But I don't manage that and don't know what it runs on. ### Database None
GiteaMirror added the issue/needs-feedbacktype/bug labels 2025-11-02 11:08:03 -06:00
GiteaMirror commented 2025-11-02 11:08:05 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 18, 2025):

That branch selector does nothing more than just record/display a name. It affects nothing.

That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar #32744 "

@wxiaoguang commented on GitHub (Mar 18, 2025): That branch selector does nothing more than just record/display a name. It affects nothing. That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar #32744 "
GiteaMirror commented 2025-11-02 11:08:05 -06:00
Author
Owner
Copy Link

@reimer-atb commented on GitHub (Mar 18, 2025):

That branch selector does nothing more than just record/display a name. It affects nothing.

It obviously causes a bug in the auto-closing issue feature. Because the issue is not auto-closed if I don't link the issue to the pull request branch.

That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar #32744 "

While the mentioned PR may have been merged it does not seem to be included in any of the upcoming releases (1.23.6 or 1.24)?

There's also #20226 (included in the 1.24.0 milestone). Won't that require again a link between issue and pull request branch?

@reimer-atb commented on GitHub (Mar 18, 2025): > That branch selector does nothing more than just record/display a name. It affects nothing. It obviously causes a bug in the auto-closing issue feature. Because the issue is not auto-closed if I don't link the issue to the pull request branch. > That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar [#32744](https://github.com/go-gitea/gitea/pull/32744) " While the mentioned PR may have been merged it does not seem to be included in any of the upcoming releases (1.23.6 or 1.24)? There's also #20226 (included in the 1.24.0 milestone). Won't that require again a link between issue and pull request branch?
GiteaMirror commented 2025-11-02 11:08:05 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 18, 2025):

While the mentioned PR may have been merged it does not seem to be included in any of the upcoming releases (1.23.6 or 1.24)?

Because that PR didn't really remove the selector. See its discussion, a user said that they still need that selector.

There's also #20226 (included in the 1.24.0 milestone). Won't that require again a link between issue and pull request branch?

That's a new proposal

@wxiaoguang commented on GitHub (Mar 18, 2025): > While the mentioned PR may have been merged it does not seem to be included in any of the upcoming releases (1.23.6 or 1.24)? Because that PR didn't really remove the selector. See its discussion, a user said that they still need that selector. > There's also [#20226](https://github.com/go-gitea/gitea/issues/20226) (included in the 1.24.0 milestone). Won't that require again a link between issue and pull request branch? That's a new proposal
GiteaMirror commented 2025-11-02 11:08:05 -06:00
Author
Owner
Copy Link

@reimer-atb commented on GitHub (Mar 18, 2025):

Because that PR didn't really remove the selector. See its discussion, a user said that they still need that selector.

Then I don't understand the relevance for this issue? If the branch selector is not going to be removed then the bug I am describing here remains, and should be fixed.

@reimer-atb commented on GitHub (Mar 18, 2025): > Because that PR didn't really remove the selector. See its discussion, a user said that they still need that selector. Then I don't understand the relevance for this issue? If the branch selector is not going to be removed then the bug I am describing here remains, and should be fixed.
GiteaMirror commented 2025-11-02 11:08:05 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 18, 2025):

From my understanding:

That branch selector does nothing more than just record/display a name. It affects nothing.

I did a quick test, using that "branch selector" doesn't have any affect, it only shows a message like root added reference root-patch-5 2 minutes ago and won't trigger "auto-close" feature.

Image

@wxiaoguang commented on GitHub (Mar 18, 2025): From my understanding: > That branch selector does nothing more than just record/display a name. It affects nothing. I did a quick test, using that "branch selector" doesn't have any affect, it only shows a message like `root added reference root-patch-5 2 minutes ago` and won't trigger "auto-close" feature. <details> ![Image](https://github.com/user-attachments/assets/ef09e4c9-ba72-474f-abaf-7b15a84c7a25) </details>
GiteaMirror commented 2025-11-02 11:08:05 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 18, 2025):

Maybe the root cause is the close #xxx phrases in commit message?

@wxiaoguang commented on GitHub (Mar 18, 2025): Maybe the root cause is the `close #xxx` phrases in commit message?
GiteaMirror commented 2025-11-02 11:08:05 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 19, 2025):

Hmm, I think I could overall understand the problem now.

It seems to be a feature from "Fix permission checks for close/reopen from commit (#8875)"

The logic is like this: if an issue #N refers to branch-X, and branch-X contains commits like close #N, then when Gitea receives the commit, then it auto closes the issue #N.

Actually you could also reproduce it by this step:

  • Create issue #N
  • Create branch branch-X
  • Use the branch selector to make issue #N refer to branch-X
  • Add a commit close #N in branch-X and push
  • Then issue #N will be closed

I guess it can't be considered as a bug since it was designed to work that way, some users used to follow this workflow.

By the way, there is even an option in repo's setting page: "Close an issue via a commit made in a non default branch", it could close an issue by a commit in any branch (but not only the "referred" one) by close #N phrase.

So maybe the solution is: do not use that branch selector if you don't need it .........

Related logic:

39fc2e7285/services/repository/push.go (L249)

39fc2e7285/services/issue/commit.go (L199)

@wxiaoguang commented on GitHub (Mar 19, 2025): Hmm, I think I could overall understand the problem now. It seems to be a feature from "Fix permission checks for close/reopen from commit (#8875)" The logic is like this: if an issue `#N` refers to `branch-X`, and `branch-X` contains commits like `close #N`, then when Gitea receives the commit, then it auto closes the issue `#N`. Actually you could also reproduce it by this step: * Create issue `#N` * Create branch `branch-X` * Use the branch selector to make issue `#N` refer to `branch-X` * Add a commit `close #N` in `branch-X` and push * Then issue `#N` will be closed I guess it can't be considered as a bug since it was designed to work that way, some users used to follow this workflow. By the way, there is even an option in repo's setting page: "Close an issue via a commit made in a non default branch", it could close an issue by a commit in any branch (but not only the "referred" one) by `close #N` phrase. ----- So maybe the solution is: do not use that branch selector if you don't need it ......... ----- Related logic: <details> https://github.com/go-gitea/gitea/blob/39fc2e728597882d4b63717287d463fd23eff1cc/services/repository/push.go#L249 https://github.com/go-gitea/gitea/blob/39fc2e728597882d4b63717287d463fd23eff1cc/services/issue/commit.go#L199 </details>
GiteaMirror commented 2025-11-02 11:08:05 -06:00
Author
Owner
Copy Link

@reimer-atb commented on GitHub (Mar 19, 2025):

By the way, there is even an option in repo's setting page: "Close an issue via a commit made in a non default branch", it could close an issue by a commit in any branch (but not only the "referred" one) by close #N phrase.

The point is that I did not enable that setting. And therefore expected that having closes #N in a commit only closes the issue if the commit is on the default branch.

At the very least, the wording of that option is not clear, and gitea's behavior is inconsistent. Because if I just do a normal push of a closes #N commit to my non-default branch-X the issue will be kept open. Only when I do a force-push to that branch after a rebase the issue get's auto-closed. That does not make any sense to me, in any workflow.

@reimer-atb commented on GitHub (Mar 19, 2025): > By the way, there is even an option in repo's setting page: "Close an issue via a commit made in a non default branch", it could close an issue by a commit in any branch (but not only the "referred" one) by close #N phrase. The point is that I did **not** enable that setting. And therefore expected that having `closes #N` in a commit **only** closes the issue **if** the commit is on the **default** branch. At the very least, the wording of that option is not clear, and gitea's behavior is inconsistent. Because if I just do a normal push of a `closes #N` commit to my non-default `branch-X` the issue will be kept open. **Only when** I do a force-push to that branch after a rebase the issue get's auto-closed. That does not make any sense to me, in any workflow.
GiteaMirror commented 2025-11-02 11:08:06 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 19, 2025):

The point is that I did not enable that setting. And therefore expected that having closes #N in a commit only closes the issue if the commit is on the default branch.

I did not say you enabled that setting. I was just explaining the whole design. I think I have said clearly that By the way (but not only ...).

Because if I just do a normal push of a closes #N commit to my non-default branch-X the issue will be kept open.

Please read the explanation above again: a commit in branch branch-X contains close #N will close the issue #N if the issue has attached to branch branch-X by the sidebar branch selector. I was just explaining the old design.

Only when I do a force-push to that branch after a rebase the issue get's auto-closed. That does not make any sense to me, in any workflow.

That's not true. A normal push also also behaves exactly the same: a commit in branch branch-X contains close #N will close the issue #N if the issue has attached to branch branch-X by the sidebar branch selector. You could try it by yourself without force-push.

@wxiaoguang commented on GitHub (Mar 19, 2025): > The point is that I did **not** enable that setting. And therefore expected that having `closes #N` in a commit **only** closes the issue **if** the commit is on the **default** branch. I did **not** say you enabled that setting. I was just explaining the whole design. I think I have said **clearly** that **By the way (but not only ...)**. > Because if I just do a normal push of a `closes #N` commit to my non-default `branch-X` the issue will be kept open. Please **read the explanation above again**: a commit in branch `branch-X` contains `close #N` will close the issue `#N` if the issue has attached to branch `branch-X` by the sidebar branch selector. I was just explaining the old design. > **Only when** I do a force-push to that branch after a rebase the issue get's auto-closed. That does not make any sense to me, in any workflow. That's **not** true. A normal push also also behaves **exactly the same**: a commit in branch `branch-X` contains `close #N` will close the issue `#N` if the issue has attached to branch `branch-X` by the sidebar branch selector. You could try it by yourself **without** force-push.
GiteaMirror commented 2025-11-02 11:08:06 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 19, 2025):

And actually I do not know why you need that branch selector to choose a branch for an issue.

So quote the comment above:

So maybe the solution is: do not use that branch selector if you don't need it .........

If you really need it, could you help to elaborate your workflow?

@wxiaoguang commented on GitHub (Mar 19, 2025): And actually I do not know why you need that branch selector to choose a branch for an issue. So quote the comment above: > So maybe the solution is: do not use that branch selector if you don't need it ......... If you really need it, could you help to elaborate your workflow?
GiteaMirror commented 2025-11-02 11:08:06 -06:00
Author
Owner
Copy Link

@reimer-atb commented on GitHub (Mar 19, 2025):

I don't really need it. And yes, now that I know that the branch selection feature is causing the bug I can work around it and not use the branch selector.

But I don't understand what point you are trying to make here? Are you saying this is not a bug? Then I would strongly disagree.

As long as this branch selection feature exists some people will use it. And they will encounter this bug that I am describing. And they will become confused and frustrated with gitea.

@reimer-atb commented on GitHub (Mar 19, 2025): I don't *really* need it. And yes, now that I know that the branch selection feature is causing the bug I can work around it and not use the branch selector. But I don't understand what point you are trying to make here? Are you saying this is not a bug? Then I would strongly disagree. As long as this branch selection feature exists some people will use it. And they will encounter this bug that I am describing. And they will become confused and frustrated with gitea.
GiteaMirror commented 2025-11-02 11:08:06 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Mar 19, 2025):

But I don't understand what point you are trying to make here? Are you saying this is not a bug? Then I would strongly disagree.

Then it comes to that background:

That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar https://github.com/go-gitea/gitea/pull/32744 "

😆

In my mind that "branch selector" is an out-dated feature, it was designed that way so it's hard to say it is really a bug or not. But I failed to remove it because some users said they still need it .....

As an open-source and crowd-contributed project, many features were written in old days and the original author maintainers are not active anymore. I am just trying to clarify everything at the moment.

To be honest, I don't quite understand how to correctly maintain this feature to satisfy every user.

@wxiaoguang commented on GitHub (Mar 19, 2025): > But I don't understand what point you are trying to make here? Are you saying this is not a bug? Then I would strongly disagree. Then it comes to that background: > That's why I suggested to remove it, see the original proposal in "Fix bug of branch/tag selector in the issue sidebar https://github.com/go-gitea/gitea/pull/32744 " 😆 In my mind that "branch selector" is an out-dated feature, it was designed that way so it's hard to say it is really a bug or not. But I failed to remove it because some users said they still need it ..... As an open-source and crowd-contributed project, many features were written in old days and the original author maintainers are not active anymore. I am just trying to clarify everything at the moment. To be honest, I don't quite understand how to correctly maintain this feature to satisfy every user.
GiteaMirror commented 2025-11-02 11:08:06 -06:00
Author
Owner
Copy Link

@GiteaBot commented on GitHub (Apr 19, 2025):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Apr 19, 2025): We close issues that need feedback from the author if there were no new comments for a month. :tea:
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/needs-feedback type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#14268
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?