-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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.
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
Retarget depending pulls when the parent branch is deleted #28686
Conversation
…erged and closed, fixes go-gitea#18408
@denyskon , my advice to review this PR. And if you read previous thread:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not against making this feature optional, but definitely enabled by default. I think it is good that retarget only occurs inside the same repo, because otherwise PRs may end up somewhere they weren't supposed to.
@kvaster If we need a test, you can add me as collaborator to your fork, then I'd try to write one. |
I think that making this as a feature is non usefull at all. I will remove with please feature gate if gitea authors/maintainers are ok with this. So, waiting for agreement on this. @denyskon, adding you as a collaborator. |
It's normal for Gitea to be able to disable everything you want, so I don't see any reason not to allow it here too 😆 It is already implemented, so let's keep it, but enable by default. I'll try to take care of the test later today |
Great. Will update PR in a few minutes. |
Co-authored-by: delvh <dev.lh@web.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've finished testing, everything behaves exactly as expected 🎉
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: delvh <dev.lh@web.de>
* giteaofficial/main: Retarget depending pulls when the parent branch is deleted (go-gitea#28686) Bump `@github/relative-time-element` to 4.3.1 (go-gitea#28819) Fix reverting a merge commit failing (go-gitea#28794) Render code block in activity tab (go-gitea#28816) Remove trust model selection from repository creation on web page because it can be changed in settings later (go-gitea#28814)
…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>
…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>
…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>
Maybe one should take a look how retargeting like this affects CI integrations like Drone, in particular. I remember having observed issues regarding that in the past. |
What do you mean? |
If there is a problem with integration with other software, just open a new issue and we see how we can address it on our side. For your specific note, tbh. that sounds more like a bug in drone-ci ... but if it realy ocures, let us know :) |
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