forgejo/forgejo

Fork 837

problem: no option to force update when posting to /contents and new_branch already exists #12600

New issue

Closed

opened 2026-05-16 23:27:55 +02:00 by rgon · 8 comments

rgon commented

2026-05-16 23:27:55 +02:00

Contributor

Does your problem still exist on the latest Forgejo version?

Yes, the problem still exists (tested locally with the latest development version)

About your usage of Forgejo

I'm working on supporting forgejo in an open-source automated release tool, https://github.com/robgonnella/releasaurus

Problem description

I am currently posting to /api/v1/repos/{owner}/{repo}/contents to update multiple files at once for a new branch; however, this call fails if new_branch already exists. I would love to have an option that would allow the "new" branch to be force updated if it already exists.

Adding this option would allow me to better support forgejo in an automated release tool I've created, https://github.com/robgonnella/releasaurus.

I was able to land a similar patch in gitea as well https://github.com/go-gitea/gitea/issues/35538, and would be happy to post a similar PR for forgejo if you are open to accepting this change.

Potential workarounds

I'm currently able to work around the issue in two ways, but both are less than ideal.

First delete the existing branch then recreate

This is problematic as any open PRs on the new branch will also be closed. The means the automated release tool will close and reopen PRs every time a commit is added to the main branch resulting in an accumulation of closed / abandoned release PRs. Additionally this approach requires waiting an arbitrary amount of time for PRs to be closed after deleting the branch before the release branch can be re-created.

releasaurus offers the option to use a locally cloned repo for git operations and then only uses forge API calls to create PRs and releases

This does fully workaround the issue but is less effective in a CI environment where releasaurus is designed to work without any direct dependency on git. This becomes more of an issue when releasaurus is being used to manage multiple projects as a hosted service as it introduces additional storage requirements.

Forgejo Version

image: codeberg.org/forgejo/forgejo:15

Other details about your environment (software names and versions)

Tested by running forgejo locally using docker as well as a hosted repo on codeberg.org

Solutions

Accepted solutions to address this problem will go here

### Does your problem still exist on the latest Forgejo version? Yes, the problem still exists (tested locally with the latest development version) ### About your usage of Forgejo I'm working on supporting forgejo in an open-source automated release tool, https://github.com/robgonnella/releasaurus ### Problem description I am currently posting to `/api/v1/repos/{owner}/{repo}/contents` to update multiple files at once for a new branch; however, this call fails if new_branch already exists. I would love to have an option that would allow the "new" branch to be force updated if it already exists. Adding this option would allow me to better support forgejo in an automated release tool I've created, https://github.com/robgonnella/releasaurus. I was able to land a similar patch in gitea as well https://github.com/go-gitea/gitea/issues/35538, and would be happy to post a similar PR for forgejo if you are open to accepting this change. ### Potential workarounds I'm currently able to work around the issue in two ways, but both are less than ideal. 1. First delete the existing branch then recreate This is problematic as any open PRs on the new branch will also be closed. The means the automated release tool will close and reopen PRs every time a commit is added to the `main` branch resulting in an accumulation of closed / abandoned release PRs. Additionally this approach requires waiting an arbitrary amount of time for PRs to be closed after deleting the branch before the release branch can be re-created. 2. `releasaurus` offers the option to use a locally cloned repo for git operations and then only uses forge API calls to create PRs and releases This does fully workaround the issue but is less effective in a CI environment where `releasaurus` is designed to work without any direct dependency on git. This becomes more of an issue when `releasaurus` is being used to manage multiple projects as a hosted service as it introduces additional storage requirements. ### Forgejo Version image: codeberg.org/forgejo/forgejo:15 ### Other details about your environment (software names and versions) Tested by running forgejo locally using docker as well as a hosted repo on codeberg.org ### Solutions *Accepted solutions to address this problem will go here*

rgon added the

problem

impact

unknown

labels

2026-05-16 23:27:55 +02:00

mahlzahn commented

2026-05-17 00:03:30 +02:00

Member

And what you want: that an option is added to reset the branch first? Thus, that the new_branch will have only the commits of branch + 1?

What is the option supposed to do if new_branch is not given?

If I understand https://codeberg.org/api/swagger#/repository/repoChangeFiles correctly, then by default each POST triggers a commit with the file modifications. And what you want: that an option is added to reset the branch first? Thus, that the `new_branch` will have only the commits of `branch` + 1? What is the option supposed to do if `new_branch` is not given?

mahlzahn commented

2026-05-17 00:07:48 +02:00

Member

As a third workaround comes to my mind:

Create a commit for each file change, by firstly getting all files https://codeberg.org/api/swagger#/repository/repoGetContentsList, create all file changes and use https://codeberg.org/api/swagger#/repository/repoChangeFiles. Maybe a bit error-prune, but doesn't have the flaws of your workarounds above.

As a third workaround comes to my mind: Create a commit for each file change, by firstly getting all files https://codeberg.org/api/swagger#/repository/repoGetContentsList, create all file changes and use https://codeberg.org/api/swagger#/repository/repoChangeFiles. Maybe a bit error-prune, but doesn't have the flaws of your workarounds above.

rgon commented

2026-05-17 00:40:23 +02:00

Author

Contributor

And what you want: that an option is added to reset the branch first? Thus, that the new_branch will have only the commits of branch + 1?

Yes this is what I would like to have. Since the underlying operation is just a push, it amounts to adding an option for push --force.

I would expect that in all cases force is applied to the targeted branch, which can be either branch or new_branch, and should be subject to the existing branch protection rules. If the user provides force and branch, but not new_branch I believe force ultimately has no effect as it's just adding a commit on top, but might be rejected just based on branch rules. I'm not sure I really see this as a flaw

The proposed 3rd workaround isn't actually a solution, it suffers from the same exact issue. Actually it is very similar to the way the release tool works currently. Instead of fetching the entire contents list, we fetch only the files we know we want to modify, create the file changes, and then use https://codeberg.org/api/swagger#/repository/repoChangeFiles - just as you have suggested. The problem is that the call to https://codeberg.org/api/swagger#/repository/repoChangeFiles will always fail if new_branch already exists, as I've described above. If new_branch already exists the API currently always returns a 422 status code.

> And what you want: that an option is added to reset the branch first? Thus, that the new_branch will have only the commits of branch + 1? Yes this is what I would like to have. Since the underlying operation is just a push, it amounts to adding an option for `push --force`. I would expect that in all cases `force` is applied to the targeted branch, which can be either `branch` or `new_branch`, and should be subject to the existing branch protection rules. If the user provides `force` and `branch`, but not `new_branch` I believe `force` ultimately has no effect as it's just adding a commit on top, but might be rejected just based on branch rules. I'm not sure I really see this as a flaw The proposed 3rd workaround isn't actually a solution, it suffers from the same exact issue. Actually it is very similar to the way the release tool works currently. Instead of fetching the entire contents list, we fetch only the files we know we want to modify, create the file changes, and then use https://codeberg.org/api/swagger#/repository/repoChangeFiles - just as you have suggested. The problem is that the call to https://codeberg.org/api/swagger#/repository/repoChangeFiles will always fail if `new_branch` already exists, as I've described above. If `new_branch` already exists the API currently always returns a 422 status code.

👍 1

rgon commented

2026-05-19 16:53:07 +02:00

Author

Contributor

@mahlzahn just curious if the team might be open to this addition? If so I'm happy to put the work in and create a PR for review. I just don't want to waste anyone's time if not something the team is willing to consider. Also thank you for taking the time to review my request! Much appreciated. And thank you for all your work on forgejo as well!

mahlzahn commented

2026-05-19 17:46:52 +02:00

Member

The proposed 3rd workaround isn't actually a solution

Yes, you’re right. The main issue I see is that e.g., a rebase would require a very complicated and heavy call to the API. Thus, not suitable.

What about following workflow for updating a PR?

merge base branch into pr branch https://codeberg.org/api/swagger#/repository/repoUpdatePullRequest with rebase option

update only the files needed with something like:

curl -X 'POST' \
  'https://codeberg.org/api/v1/repos/owner/repo/contents' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "branch": "prepare/release",
  "files": [
    {
      "content": "a3au39wuio3ia3…",
      "operation": "update",
      "path": "RELEASE_NOTES",
      "sha": "11313fag3a311…"
    }
  ],
  "message": "chore: update"
}'

Or doesn’t that work for you? I didn’t try it, but I’d expect that you can just add more commits like that (without new_branch). At least if you only change few files?

just curious if the team might be open to this addition

I can’t answer you on that, yet. For me these contents API seems a bit weird (because there is Git) and I wasn’t even aware of them to exist. But, they exist and thus, maybe should cover cases like yours. I don’t know.

> The proposed 3rd workaround isn't actually a solution Yes, you’re right. The main issue I see is that e.g., a rebase would require a very complicated and heavy call to the API. Thus, not suitable. What about following workflow for updating a PR? 1. merge base branch into pr branch https://codeberg.org/api/swagger#/repository/repoUpdatePullRequest with rebase option 2. update only the files needed with something like: ```sh curl -X 'POST' \ 'https://codeberg.org/api/v1/repos/owner/repo/contents' \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "branch": "prepare/release", "files": [ { "content": "a3au39wuio3ia3…", "operation": "update", "path": "RELEASE_NOTES", "sha": "11313fag3a311…" } ], "message": "chore: update" }' ``` Or doesn’t that work for you? I didn’t try it, but I’d expect that you can just add more commits like that (without `new_branch`). At least if you only change few files? > just curious if the team might be open to this addition I can’t answer you on that, yet. For me these `contents` API seems a bit weird (because there is Git) and I wasn’t even aware of them to exist. But, they exist and thus, maybe should cover cases like yours. I don’t know.

rgon commented

2026-05-19 19:02:22 +02:00

Author

Contributor

This is an interesting approach. Thank you for the lead, somehow I missed this /pulls/{index}/update route. I'll give it a try but I worry it might still fall short of the desired outcome.

The idea is that the release branch only contains a single commit - something of the form chore(<branch>): release .... In the case where users are using rebase / fast-forward / squash merge-method, the resulting single commit gets tagged. In the case where they are using merge-commit as the merge-method, the merge commit gets tagged.

Branch creation, PR creation / updates, changelog updates, manifest version updates, tagging, and release creation are all fully automated. In this flow, having a release branch / PR with potentially hundreds of the same commit message is probably not going to work. FWIW github, gitlab, gitea, and azure-devops are all supported in this workflow.

This is an interesting approach. Thank you for the lead, somehow I missed this `/pulls/{index}/update` route. I'll give it a try but I worry it might still fall short of the desired outcome. The idea is that the release branch only contains a single commit - something of the form `chore(<branch>): release ...`. In the case where users are using rebase / fast-forward / squash merge-method, the resulting single commit gets tagged. In the case where they are using merge-commit as the merge-method, the merge commit gets tagged. Branch creation, PR creation / updates, changelog updates, manifest version updates, tagging, and release creation are all fully automated. In this flow, having a release branch / PR with potentially hundreds of the same commit message is probably not going to work. FWIW github, gitlab, gitea, and azure-devops are all supported in this workflow.

rgon commented

2026-05-21 02:20:02 +02:00

Author

Contributor

I found some time to test the /pulls/{index}/update approach and I was able to successfully rebase the release branch and add new changelog / manifest version update commits for each incoming commit on the base branch.

However, this would accumulate potentially hundreds of commits on the release branch, all with similar titles. I could document this and instruct our users that they need to either squash the commits when merging, or use the alternate "local-path" hybrid mode offered in releasaurus. I do think offering a way to force push the target branch through API calls is a reasonable change though, and is offered in other forge APIs. I will attempt to create a PR for this functionality and see if I can get some traction.

I found some time to test the `/pulls/{index}/update` approach and I was able to successfully rebase the release branch and add new changelog / manifest version update commits for each incoming commit on the base branch. However, this would accumulate potentially hundreds of commits on the release branch, all with similar titles. I _could_ document this and instruct our users that they need to either squash the commits when merging, or use the alternate "local-path" hybrid mode offered in releasaurus. I do think offering a way to force push the target branch through API calls is a reasonable change though, and is offered in other forge APIs. I will attempt to create a PR for this functionality and see if I can get some traction.

mahlzahn commented

2026-05-21 08:30:34 +02:00

Member

Great that this workaround is working :)

Maybe an option force_overwrite_new_branch could be an option to only be used when both branch and new_branch are given?

Great that this workaround is working :) Maybe an option `force_overwrite_new_branch` could be an option to only be used when both `branch` and `new_branch` are given?

👍 1

rgon referenced this issue from a commit

2026-05-21 14:49:23 +02:00

feat: adds option to force overwrite new branch for /contents route

rgon referenced this issue from a commit

2026-05-21 15:04:10 +02:00

feat: adds option to force overwrite new branch for /contents route

rgon referenced this issue

2026-05-21 15:05:59 +02:00

feat: adds option to force overwrite new branch for /contents route #12663

rgon referenced this issue from a commit

2026-05-21 15:13:39 +02:00