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

Allow cascade PRs #18408

Closed
kvaster opened this issue Jan 25, 2022 · 9 comments · Fixed by #28686
Closed

Allow cascade PRs #18408

kvaster opened this issue Jan 25, 2022 · 9 comments · Fixed by #28686
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@kvaster
Copy link
Contributor

kvaster commented Jan 25, 2022

Feature Description

Sometime you need to have 'cascade' PRs. i.e.

  • first you're working on feature A (derived from main branch) and you create PR feature A -> main
  • next you need to work on feature B, but this feature depends on changes of feature A and it's corresponding PR is not yet approved. The best way to work on such feature is derive from feature A and later you need to create PR feature B -> feature A.

Currently second PR will be automatically closed on feature A merge and branch delete. It would be helpfull to rebase second PR. i.e. change 'feature B -> feature A' to 'feature B -> main' when first 'feature A -> main' is merged and 'feature A' branch is deleted.

Screenshots

No response
@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Jan 26, 2022
@lunny
Copy link
Member

lunny commented Jan 26, 2022

Could you reopen it and rebase to main?

@kvaster
Copy link
Contributor Author

kvaster commented Jan 27, 2022

It's not possible to reopen and rebase PR: This pull request cannot be reopened because the branch was deleted.

@lunny
Copy link
Member

lunny commented Jan 29, 2022

Then you can check out the pull request and create a new one.

@kvaster
Copy link
Contributor Author

kvaster commented Jan 31, 2022

Then you can check out the pull request and create a new one.

You may, but review in-progress will be lost in this case.

kvaster added a commit to kvaster/gitea that referenced this issue May 8, 2022
@kvaster
Try to keep branch PRs open when branch is deleted cause of it's PR m…
91de000 
…erged and closed, fixes go-gitea#18408
@6543 6543 mentioned this issue May 8, 2022
Closed
kvaster added a commit to kvaster/gitea that referenced this issue Mar 26, 2023
@kvaster
Try to keep branch PRs open when branch is deleted cause of it's PR m…
795d8cb 
…erged and closed, fixes go-gitea#18408
@LeafyLappa
Copy link

Then you can check out the pull request and create a new one.

You may, but review in-progress will be lost in this case.

came across this exact problem, very frustrating.

@xav-ie
Copy link

xav-ie commented Nov 14, 2023

Re-opening is not an option because my team will spend time reviewing that PR and all the comments and discussion dissappear on re-open.

@xav-ie
Copy link

xav-ie commented Nov 14, 2023

gh pr merge has same issue cli/cli#8331 ... maybe they are connected?

@niekvanderkooy niekvanderkooy mentioned this issue Dec 7, 2023
Closed
@denyskon
Copy link
Member

denyskon commented Jan 3, 2024

Closing in favor of #27062 which will soon be fixed by #28539

@denyskon denyskon closed this as completed Jan 3, 2024
@kvaster
Copy link
Contributor Author

kvaster commented Jan 3, 2024

@denyskon , see my comments in #28539.

kvaster added a commit to kvaster/gitea that referenced this issue Jan 3, 2024
@kvaster
Try to keep branch PRs open when branch is deleted cause of it's PR m…
1fd16f9 
…erged and closed, fixes go-gitea#18408
@kvaster kvaster mentioned this issue Jan 3, 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>
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 18, 2024
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>
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
5 participants
@lunny @kvaster @xav-ie @LeafyLappa @denyskon