Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Changing the destination branch of a pull request after deletion #27062

Closed
tulzke opened this issue Sep 13, 2023 · 3 comments · Fixed by #28686
Closed

Changing the destination branch of a pull request after deletion #27062

tulzke opened this issue Sep 13, 2023 · 3 comments · Fixed by #28686
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@tulzke
Copy link

tulzke commented Sep 13, 2023

Feature Description

branch3 -> branch2 -> branch1 -> master
Now, if we have a chain of pull requests, we cannot merge branch1 first, because all other requests to branch1 will be closed without the possibility of reopening.

In bitbucket, this was solved by the fact that when deleting a branch1, all open pull requests change the target to the branch into which branch1 was merged, in our case, this is the master.

Screenshots

Here is an example in the form of a mind map.
Schema before merge branch1:
Before merge
After merge and deleting branch1:
After merge
@tulzke tulzke added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Sep 13, 2023
@lunny
Copy link
Member

lunny commented Sep 14, 2023

Retargeting all pull requests targeted branch1 to master sounds reasonable. Or we can have a prompt dialog to let users choose when deleting?

@tulzke
Copy link
Author

tulzke commented Sep 14, 2023

Retargeting all pull requests targeted branch1 to master sounds reasonable. Or we can have a prompt dialog to let users choose when deleting?

Only before we merge branch1. It's easy to forget to do that. Why not do it automatically, as it is implemented in Bitbucket

@tulzke tulzke mentioned this issue Dec 19, 2023
Closed
@denyskon denyskon mentioned this issue Jan 3, 2024
Closed
@denyskon denyskon mentioned this issue Jan 14, 2024
Merged
delvh added a commit that referenced this issue Jan 17, 2024
@kvaster @denyskon @delvh
Retarget depending pulls when the parent branch is deleted (#28686)
49eb168 
Sometimes you need to work on a feature which depends on another (unmerged) feature.
In this case, you may create a PR based on that feature instead of the main branch.
Currently, such PRs will be closed without the possibility to reopen in case the parent feature is merged and its branch is deleted.
Automatic target branch change make life a lot easier in such cases.
Github and Bitbucket behave in such way.

Example:
$PR_1$: main <- feature1
$PR_2$: feature1 <- feature2

Currently, merging $PR_1$ and deleting its branch leads to $PR_2$ being closed without the possibility to reopen.
This is both annoying and loses the review history when you open a new PR.

With this change, $PR_2$ will change its target branch to main ($PR_2$: main <- feature2) after $PR_1$ has been merged and its branch has been deleted.

This behavior is enabled by default but can be disabled.
For security reasons, this target branch change will not be executed when merging PRs targeting another repo. 

Fixes #27062
Fixes #18408

---------

Co-authored-by: Denys Konovalov <kontakt@denyskon.de>
Co-authored-by: delvh <dev.lh@web.de>
fuxiaohei pushed a commit to fuxiaohei/gitea that referenced this issue Jan 17, 2024
@kvaster @denyskon
@delvh @fuxiaohei
Retarget depending pulls when the parent branch is deleted (go-gitea#…
78c29de 
…28686)

Sometimes you need to work on a feature which depends on another (unmerged) feature.
In this case, you may create a PR based on that feature instead of the main branch.
Currently, such PRs will be closed without the possibility to reopen in case the parent feature is merged and its branch is deleted.
Automatic target branch change make life a lot easier in such cases.
Github and Bitbucket behave in such way.

Example:
$PR_1$: main <- feature1
$PR_2$: feature1 <- feature2

Currently, merging $PR_1$ and deleting its branch leads to $PR_2$ being closed without the possibility to reopen.
This is both annoying and loses the review history when you open a new PR.

With this change, $PR_2$ will change its target branch to main ($PR_2$: main <- feature2) after $PR_1$ has been merged and its branch has been deleted.

This behavior is enabled by default but can be disabled.
For security reasons, this target branch change will not be executed when merging PRs targeting another repo. 

Fixes go-gitea#27062
Fixes go-gitea#18408

---------

Co-authored-by: Denys Konovalov <kontakt@denyskon.de>
Co-authored-by: delvh <dev.lh@web.de>
henrygoodman pushed a commit to henrygoodman/gitea that referenced this issue Jan 31, 2024
@kvaster @denyskon
@delvh @henrygoodman
Retarget depending pulls when the parent branch is deleted (go-gitea#…
dc5307d 
…28686)

Sometimes you need to work on a feature which depends on another (unmerged) feature.
In this case, you may create a PR based on that feature instead of the main branch.
Currently, such PRs will be closed without the possibility to reopen in case the parent feature is merged and its branch is deleted.
Automatic target branch change make life a lot easier in such cases.
Github and Bitbucket behave in such way.

Example:
$PR_1$: main <- feature1
$PR_2$: feature1 <- feature2

Currently, merging $PR_1$ and deleting its branch leads to $PR_2$ being closed without the possibility to reopen.
This is both annoying and loses the review history when you open a new PR.

With this change, $PR_2$ will change its target branch to main ($PR_2$: main <- feature2) after $PR_1$ has been merged and its branch has been deleted.

This behavior is enabled by default but can be disabled.
For security reasons, this target branch change will not be executed when merging PRs targeting another repo. 

Fixes go-gitea#27062
Fixes go-gitea#18408

---------

Co-authored-by: Denys Konovalov <kontakt@denyskon.de>
Co-authored-by: delvh <dev.lh@web.de>
silverwind pushed a commit to silverwind/gitea that referenced this issue Feb 20, 2024
@kvaster @denyskon
@delvh @silverwind
Retarget depending pulls when the parent branch is deleted (go-gitea#…
ea45dfc 
…28686)

Sometimes you need to work on a feature which depends on another (unmerged) feature.
In this case, you may create a PR based on that feature instead of the main branch.
Currently, such PRs will be closed without the possibility to reopen in case the parent feature is merged and its branch is deleted.
Automatic target branch change make life a lot easier in such cases.
Github and Bitbucket behave in such way.

Example:
$PR_1$: main <- feature1
$PR_2$: feature1 <- feature2

Currently, merging $PR_1$ and deleting its branch leads to $PR_2$ being closed without the possibility to reopen.
This is both annoying and loses the review history when you open a new PR.

With this change, $PR_2$ will change its target branch to main ($PR_2$: main <- feature2) after $PR_1$ has been merged and its branch has been deleted.

This behavior is enabled by default but can be disabled.
For security reasons, this target branch change will not be executed when merging PRs targeting another repo. 

Fixes go-gitea#27062
Fixes go-gitea#18408

---------

Co-authored-by: Denys Konovalov <kontakt@denyskon.de>
Co-authored-by: delvh <dev.lh@web.de>
@github-actions GitHub Actions
Copy link

github-actions bot commented Mar 1, 2024

Automatically locked because of our CONTRIBUTING guidelines

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Milestone
No milestone
2 participants
@lunny @tulzke