Edit head_branch of a PR

[AdamMajer]

Feature Description

In a typical workflow,

1. do some changes on branch foo
2. create a PR
3. add some commits to branch foo
4. PR is updated

Now, how can I turn this automatic branch following off?

The reason is specific workflows that can run long time and where changes on the source branch may not be wanted in the PR.

In the API https://demo.gitea.com/api/swagger/#/repository/repoEditPullRequest I can't set the HEAD branch to another branch. The other branch could even refer to same commitid.

Screenshots

No response

[wxiaoguang]

The reason is specific workflows that can run long time and where changes on the source branch may not be wanted in the PR.

It sounds like something "skip ci"?

[AdamMajer]

It's not about CI. It's more analogous to merging from a devel branch to a stable branch when maintainer of the stable branch likes it. But instead of creating a new label, they just do a PR from devel -> stable.

I guess a workaround could be to close the original PR and replace it with another where the commit id is on a "PR_to_stable" branch and not devel branch itself. But it would be nice to be able to do this via API, and "retarget" the source of the PR to specific commit id.

[wxiaoguang]

Hmm, I think it's almost impossible at the moment. The PR system's design is "a PR always follows its branch", this mechanism is widely used everywhere in code.

[AdamMajer]

That's fine, but it would be nice to be able to at least retarget to a different source branch name that the tooling creates.

[AdamMajer]

I see that this requires branches everywhere. So, having ability to reset the branch to different branch would be sufficient here.

[AdamMajer]

I will hijack this to be able to detach source branches (HEAD branch) by adding functionality to switch between AGit and GitHub style PR.

Changing from GitHub style PR to AGit style PR is exactly what needs to be done here.

One question -- can maintainers amend or force push to AGit style PRs?

[a1012112796]

Now, how can I turn this automatic branch following off?

why not fork a new branch name as for-pr-only/fool (name example) from fool, then you can using for-pr-only/fool as head branch to create the pull request, then you can contine working on fool branch without updating the pull request and mege fool into for-pr-only/fool when you think it's ready to update the pull request.

[AdamMajer]

Creating a new branch and then using it as a source is perfectly valid, but this should be default workflow mostly hidden by automation, hence the need to do this after a PR is created. Also, these repositories are mostly read-only to most people working on them 😉 so they cannot create branches.

In the way we use Git is that branches represent state of projects. So, let's say we have branches,

• dev
• main
• old

Now, let's suppose some fix is applied to main and this entire version is then "copied" over to old branch. We do a PR from main to old.

Automation also needs to make sure that PRs from one of these branches to another is not followed.

But all of this is mostly our niche requirement here and hence my problem, not really a Gitea usability issue.