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

Deleting a branch breaks all PRs with this branch as target #8740

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

Originally created by @delvh on GitHub (Mar 23, 2022).

Description

Currently, when you delete a branch, all PRs still targeting this branch will be closed forever, breaking them completely if you intend to merge them into another branch, i.e. the target branch of a PR that deleted the branch.
The result of this bug is that even if you attempt to reopen such a PR, you simply won't be able to:
The PR cannot be reopened because the branch does not exist, and the branch can't be changed because the PR is closed.

Reproduction Steps

  1. Create the first branch with some changes
  2. Create the second branch with more changes from the first branch
  3. Open PRs in both branches, with the first branch targeting anything, and the second branch targeting the first branch
  4. Merge the PR of the first branch, making sure to delete the first branch with it
  5. Enjoy the second PR being broken

Reproduction PR: https://try.gitea.io/delvh/kanban-test/pulls/23

Possible Solutions

  • Allow changing the target branches for closed (but not merged?) PRs (most likely solution)
  • Allow (re)opening PRs whose target branch is missing (unlikely, leads to too many errors)
  • Automatically change the target of such PRs to the target of the closing branch (unlikely, works only in the reproduction setup, and is somewhat counter-intuitive for a user)

Gitea Version

1.16.4 to 1.17.0+dev-327-gf7883a6ae

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

image
(The red box in this case comes from trying to edit the target branch to reopen the PR)

Git Version

No response

Operating System

No response

How are you running Gitea?

try.gitea.io

Database

No response

Originally created by @delvh on GitHub (Mar 23, 2022). ### Description Currently, when you delete a branch, all PRs still targeting this branch will be closed forever, breaking them completely if you intend to merge them into another branch, i.e. the target branch of a PR that deleted the branch. The result of this bug is that even if you attempt to reopen such a PR, you simply won't be able to: The PR cannot be reopened because the branch does not exist, and the branch can't be changed because the PR is closed. ## Reproduction Steps 1. Create the first branch with some changes 2. Create the second branch with more changes from the first branch 3. Open PRs in both branches, with the first branch targeting anything, and the second branch targeting the first branch 4. Merge the PR of the first branch, making sure to delete the first branch with it 5. Enjoy the second PR being broken Reproduction PR: https://try.gitea.io/delvh/kanban-test/pulls/23 ## Possible Solutions - Allow changing the target branches for closed (but not merged?) PRs (most likely solution) - Allow (re)opening PRs whose target branch is missing (unlikely, leads to too many errors) - Automatically change the target of such PRs to the target of the closing branch (unlikely, works only in the reproduction setup, and is somewhat counter-intuitive for a user) ### Gitea Version 1.16.4 to 1.17.0+dev-327-gf7883a6ae ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots ![image](https://user-images.githubusercontent.com/51889757/159800309-2494aa38-4f5d-40f1-9cf2-634cec686f08.png) (The red box in this case comes from trying to edit the target branch to reopen the PR) ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? try.gitea.io ### Database _No response_
GiteaMirror added the issue/needs-feedbacktype/bug labels 2025-11-02 08:16:05 -06:00
GiteaMirror commented 2025-11-02 08:16:07 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Mar 25, 2022):

This is an enhancement rather than a bug imo.

@lunny commented on GitHub (Mar 25, 2022): This is an enhancement rather than a bug imo.
GiteaMirror commented 2025-11-02 08:16:07 -06:00
Author
Owner
Copy Link

@delvh commented on GitHub (Mar 25, 2022):

I'd absolutely say that this is a bug since no one expects that it will be forever impossible to reopen a PR.
A dead unmerged PR is in my opinion absolutely a bug.
The only workaround for this is to explicitly visit the base branch of the dead PR and click on New Pull Request, which loses all previous data from the PR such as worked times, comments and other metadata.
All in all a pretty work-intensive bug once it occurs.

@delvh commented on GitHub (Mar 25, 2022): I'd absolutely say that this is a bug since no one expects that it will be forever impossible to reopen a PR. A dead unmerged PR is in my opinion absolutely a bug. The only workaround for this is to explicitly visit the base branch of the dead PR and click on `New Pull Request`, which loses all previous data from the PR such as worked times, comments and other metadata. All in all a pretty work-intensive bug once it occurs.
GiteaMirror commented 2025-11-02 08:16:07 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Oct 21, 2022):

What's the behaviors of Github or GitLab?

@lunny commented on GitHub (Oct 21, 2022): What's the behaviors of Github or GitLab?
GiteaMirror commented 2025-11-02 08:16:07 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Oct 24, 2022):

What's the behaviors of Github or GitLab?

I just have tested. Github also will not support change a closed PR's target branch. So I think this should not be a bug but a proposal.

@lunny commented on GitHub (Oct 24, 2022): > What's the behaviors of Github or GitLab? I just have tested. Github also will not support change a closed PR's target branch. So I think this should not be a bug but a proposal.
GiteaMirror commented 2025-11-02 08:16:07 -06:00
Author
Owner
Copy Link

@rudolphfroger commented on GitHub (Jan 25, 2023):

Another solution is to not allow merging a PR for a branch which is the target branch for other PRs. For me that would be the most correct and explicit option since it seems weird that you can merge PR that others depend on.

If it would work like this then people would first need to change the target branch for other PRs before they can merge the PR which was the target for them. That way PRs aren't closed automatically anymore, and it's clear what is happening for everyone.

@rudolphfroger commented on GitHub (Jan 25, 2023): Another solution is to not allow merging a PR for a branch which is the target branch for other PRs. For me that would be the most correct and explicit option since it seems weird that you can merge PR that others depend on. If it would work like this then people would first need to change the target branch for other PRs before they can merge the PR which was the target for them. That way PRs aren't closed automatically anymore, and it's clear what is happening for everyone.
GiteaMirror commented 2025-11-02 08:16:08 -06:00
Author
Owner
Copy Link

@flyasky commented on GitHub (Jun 13, 2023):

What's the behaviors of Github or GitLab?

Gitlab preserves PRs if the original branch (to which we are targeting this PR) is merged. You have an option to retarget dependent branch into develop.

When you work within big team with multiple branches started from unmerged one and targeted to this one, You will got into the situation when all dependent PRs are closed, review comments are in the closed PRs. It's just a good reason to switch to gitlab.

@flyasky commented on GitHub (Jun 13, 2023): > What's the behaviors of Github or GitLab? Gitlab preserves PRs if the original branch (to which we are targeting this PR) is merged. You have an option to retarget dependent branch into develop. When you work within big team with multiple branches started from unmerged one and targeted to this one, You will got into the situation when all dependent PRs are closed, review comments are in the closed PRs. It's just a good reason to switch to gitlab.
GiteaMirror commented 2025-11-02 08:16:08 -06:00
Author
Owner
Copy Link

@flyasky commented on GitHub (Jun 13, 2023):

What's the behaviors of Github or GitLab?

I just have tested. Github also will not support change a closed PR's target branch. So I think this should not be a bug but a proposal.

Gitea is autoclosing PRs if target branch is deleted (original PR is merged). This auto operation has to be avoided.

@flyasky commented on GitHub (Jun 13, 2023): > > What's the behaviors of Github or GitLab? > > I just have tested. Github also will not support change a closed PR's target branch. So I think this should not be a bug but a proposal. Gitea is **autoclosing** PRs if target branch is deleted (original PR is merged). This auto operation has to be avoided.
GiteaMirror commented 2025-11-02 08:16:08 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jun 14, 2023):

Yes, maybe we need a confirmation dialogue and list all pull requests which target branch is it.

@lunny commented on GitHub (Jun 14, 2023): Yes, maybe we need a confirmation dialogue and list all pull requests which target branch is it.
GiteaMirror commented 2025-11-02 08:16:08 -06:00
Author
Owner
Copy Link

@jtran commented on GitHub (Oct 18, 2023):

To allow stacked PRs, if the target branch A is deleted due to being merged into another branch B, then the stacked PR should get automatically retargeted to B.

GitHub has been doing this since 2020. Stacking PRs is a pretty common use case, and it would resolve many instances of running into this problem. I'm guessing the vast majority of cases.

@jtran commented on GitHub (Oct 18, 2023): To allow stacked PRs, if the target branch A is deleted due to being merged into another branch B, then the stacked PR should get automatically retargeted to B. GitHub has been doing this [since 2020](https://github.blog/changelog/2020-05-19-pull-request-retargeting/). Stacking PRs is a pretty common use case, and it would resolve many instances of running into this problem. I'm guessing the vast majority of cases.
GiteaMirror commented 2025-11-02 08:16:09 -06:00
Author
Owner
Copy Link

@jtran commented on GitHub (May 20, 2024):

Is this resolved by #28686?

@jtran commented on GitHub (May 20, 2024): Is this resolved by #28686?
GiteaMirror commented 2025-11-02 08:16:09 -06:00
Author
Owner
Copy Link

@GiteaBot commented on GitHub (Jun 21, 2024):

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

@GiteaBot commented on GitHub (Jun 21, 2024): 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#8740
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?