This pull request is broken due to missing fork information. #8575

@FrankCui-FengqiaoCui commented on GitHub (May 31, 2022):

this issue still exists in the latest try.gitea.io w/ 1.17 dev, is there any plan to fix it?

@FrankCui-FengqiaoCui commented on GitHub (May 31, 2022): this issue still exists in the latest try.gitea.io w/ 1.17 dev, is there any plan to fix it?

GiteaMirror commented

@lihanglin commented on GitHub (Jun 1, 2022):

I am using the released version 1.16.7 and have the same symptom.

@lihanglin commented on GitHub (Jun 1, 2022): I am using the released version 1.16.7 and have the same symptom.

GiteaMirror commented

@singuliere commented on GitHub (Jun 1, 2022):

@lihanglin are you using the Gitea image provided in Docker? If you do, can you please show the output of

docker --version

@singuliere commented on GitHub (Jun 1, 2022): @lihanglin are you using the Gitea image provided in Docker? If you do, can you please show the output of ``` docker --version ```

GiteaMirror commented

@lihanglin commented on GitHub (Jun 2, 2022):

@singuliere
Sorry not to clarify the scenario.
I am using the offical prebuild amd64 gitea image which version is 1,16,7 and deployed native w/o docker.

@lihanglin commented on GitHub (Jun 2, 2022): @singuliere Sorry not to clarify the scenario. I am using the offical prebuild amd64 gitea image which version is 1,16,7 and deployed native w/o docker.

GiteaMirror commented

https://try.gitea.io/arandomer/pathological/graph?branch=refs%2Fheads%2Fbe-broken&branch=refs%2Fpull%2F25%2Fhead

@zeripath commented on GitHub (Jun 3, 2022):

@FrankCui-FengqiaoCui - please check your docker version. 1.17 is running alpine > 3.13 #18500 and docker versions less than 20.10.6 will break with hooks not running.

@lihanglin - I need to know more about your situation.

I would guess that in all of these cases hooks are not running.

If that is the case the PR head ref will not be being updated at the time of updates to the PR branch head.

You can check this, and the simplest way to do this would be to go to a repository that is affected and look at /graph

Look at the head branch of PR and where the associated label of the PR is e.g. https://try.gitea.io/arandomer/pathological/pulls/25 has the head branch be-broken

So the commit graph would be:

and you can see that these are at the same position. (as they should be.)

If you have the heads at different places then my first suspicion is that you don't have hooks running and we need to go back down the rabbit hole of looking at that. The biggest causes for this are:

noexec mounting of gitea repositories
on 1.17 or anyone running alpine 3.14+ this will be old docker versions causing seccomp failures.
previously people had problems with strict permissions on systemd on arch.

If the heads are the same - well then we're gonna need logs, a reproducing testcase, and more information than "this is a serious bug" etc.

@zeripath commented on GitHub (Jun 3, 2022): @FrankCui-FengqiaoCui - please check your docker version. 1.17 is running alpine > 3.13 #18500 and docker versions less than 20.10.6 will break with hooks not running. @lihanglin - I need to know more about your situation. --- I would guess that in all of these cases hooks are not running. If that is the case the PR head ref will not be being updated at the time of updates to the PR branch head. You can check this, and the simplest way to do this would be to go to a repository that is affected and look at /graph Look at the head branch of PR and where the associated label of the PR is e.g. https://try.gitea.io/arandomer/pathological/pulls/25 has the head branch `be-broken` So the commit graph would be: https://try.gitea.io/arandomer/pathological/graph?branch=refs%2Fheads%2Fbe-broken&branch=refs%2Fpull%2F25%2Fhead and you can see that these are at the same position. (as they should be.) --- If you have the heads at different places then my first suspicion is that you don't have hooks running and we need to go back down the rabbit hole of looking at that. The biggest causes for this are: 1. noexec mounting of gitea repositories 2. on 1.17 or anyone running alpine 3.14+ this will be old docker versions causing seccomp failures. 3. previously people had problems with strict permissions on systemd on arch. If the heads are the same - well then we're gonna need logs, a reproducing testcase, and more information than "this is a serious bug" etc.

GiteaMirror commented

@lihanglin commented on GitHub (Jun 3, 2022):

@zeripath
Thanks for your response.
I will get more dig to know if my hook went wrong.
If I have more clue, I would share with you all.

@lihanglin commented on GitHub (Jun 3, 2022): @zeripath Thanks for your response. I will get more dig to know if my hook went wrong. If I have more clue, I would share with you all.

GiteaMirror commented

@penguineer commented on GitHub (Jul 6, 2022):

Could this be related to #18189 ?
(I had the similar issue due to a missed breaking change in the configuration.)

@penguineer commented on GitHub (Jul 6, 2022): Could this be related to #18189 ? (I had the similar issue due to a missed breaking change in the configuration.)

GiteaMirror commented

@amvasilyev commented on GitHub (Aug 11, 2022):

Hello. We have stumbled upon this issue after migrating to 1.17.0. We have been using 1.16.8 before that and there was no such error.

Any PR that is opened in Gitea is moving to the state 'This pull request is broken due to missing fork information.' after the new commits are added to the tracking branch.

This may be related with the fact that new commits are no longer displayed in the feed on the starting screen.

Docker version 19.03.2, build 6a30dfca03
gitea/gitea 1.17.0 71d4bdcd6398 11 days ago 247MB

Currently the host machine is Debian Stretch and I am currently stuck with 19.03 engine.

@amvasilyev commented on GitHub (Aug 11, 2022): Hello. We have stumbled upon this issue after migrating to 1.17.0. We have been using 1.16.8 before that and there was no such error. Any PR that is opened in Gitea is moving to the state 'This pull request is broken due to missing fork information.' after the new commits are added to the tracking branch. This may be related with the fact that new commits are no longer displayed in the feed on the starting screen. Docker version 19.03.2, build 6a30dfca03 gitea/gitea 1.17.0 71d4bdcd6398 11 days ago 247MB Currently the host machine is Debian Stretch and I am currently stuck with 19.03 engine.

GiteaMirror commented

@amvasilyev commented on GitHub (Aug 11, 2022):

I think that the issue is definitely in heads not being updated. I got to the testing repository:

# git show-ref
7c6241b4e54d5ef80ebf0d855466d300a07aa59e refs/heads/master
0093d051c30d314cd850ecb4c5941c9ce29aadc6 refs/heads/pr-test
da0b31358e8e7aab1da9a8a9ea77232d1436884c refs/pull/1/head

The gitea is storing data directly on the host machine:

    volumes:
      - /srv/gitea/data:/data

@amvasilyev commented on GitHub (Aug 11, 2022): I think that the issue is definitely in heads not being updated. I got to the testing repository: ``` # git show-ref 7c6241b4e54d5ef80ebf0d855466d300a07aa59e refs/heads/master 0093d051c30d314cd850ecb4c5941c9ce29aadc6 refs/heads/pr-test da0b31358e8e7aab1da9a8a9ea77232d1436884c refs/pull/1/head ``` The gitea is storing data directly on the host machine: ``` volumes: - /srv/gitea/data:/data ```

GiteaMirror commented

@99rgosse commented on GitHub (Aug 11, 2022):

Hello. We have stumbled upon this issue after migrating to 1.17.0. We have been using 1.16.8 before that and there was no such error.

I could reproduce 👍
I have a production server with Gitea 1.16.8, and a development server which is under v1.17

I brought the backups from 1.16.8 to 1.17
Opened a PR that was needing a rebase

2022/08/11 08:46:20 [62f497eb-28] router: slow POST /myrepo/myrepo/pulls/3791/update?style=rebase for 10.0.2.2:59331, elapsed 3107.4ms @ repo/pull.go:805(repo.UpdatePullRequest)
2022/08/11 08:46:22 [62f4a5be] router: completed POST /api/internal/hook/pre-receive/myrepo/myrepo for 127.0.0.1:38792, 200 OK in 16.6ms @ private/hook_pre_receive.go:108(private.HookPreReceive)
2022/08/11 08:46:22 router: completed POST /api/internal/hook/post-receive/myrepo/myrepo for 127.0.0.1:38794, 200 OK in 10.7ms @ private/hook_post_receive.go:28(private.HookPostReceive)

2022/08/11 08:46:23 ...s/repository/push.go:41:handle() [E] pushUpdate failed: gitRepo.GetCommit: object does not exist [id: 6ce324747488fd74bc7c77ee6d5bb0d20f292891, rel_path: ]

2022/08/11 08:46:23 [62f4a5b9] router: completed POST /myrepo/myrepo/pulls/3791/update?style=rebase for 10.0.2.2:59331, 303 See Other in 6404.6ms @ repo/pull.go:805(repo.UpdatePullRequest)
2022/08/11 08:46:24 [62f4a5bf-16] router: completed GET /myrepo/myrepo/pulls/3791 for 10.0.2.2:59331, 200 OK in 251.5ms @ repo/issue.go:1122(repo.ViewIssue)

This pull request is broken due to missing fork information

Now that I can reproduce, I will debug it

@99rgosse commented on GitHub (Aug 11, 2022): > Hello. We have stumbled upon this issue after migrating to 1.17.0. We have been using 1.16.8 before that and there was no such error. I could reproduce 👍 I have a production server with Gitea 1.16.8, and a development server which is under v1.17 - I brought the backups from 1.16.8 to 1.17 - Opened a PR that was needing a rebase > 2022/08/11 08:46:20 [62f497eb-28] router: slow POST /myrepo/myrepo/pulls/3791/update?style=rebase for 10.0.2.2:59331, elapsed 3107.4ms @ repo/pull.go:805(repo.UpdatePullRequest) > 2022/08/11 08:46:22 [62f4a5be] router: completed POST /api/internal/hook/pre-receive/myrepo/myrepo for 127.0.0.1:38792, 200 OK in 16.6ms @ private/hook_pre_receive.go:108(private.HookPreReceive) > 2022/08/11 08:46:22 router: completed POST /api/internal/hook/post-receive/myrepo/myrepo for 127.0.0.1:38794, 200 OK in 10.7ms @ private/hook_post_receive.go:28(private.HookPostReceive) > 2022/08/11 08:46:23 ...s/repository/push.go:41:handle() [E] pushUpdate failed: gitRepo.GetCommit: object does not exist [id: 6ce324747488fd74bc7c77ee6d5bb0d20f292891, rel_path: ] > 2022/08/11 08:46:23 [62f4a5b9] router: completed POST /myrepo/myrepo/pulls/3791/update?style=rebase for 10.0.2.2:59331, 303 See Other in 6404.6ms @ repo/pull.go:805(repo.UpdatePullRequest) > 2022/08/11 08:46:24 [62f4a5bf-16] router: completed GET /myrepo/myrepo/pulls/3791 for 10.0.2.2:59331, 200 OK in 251.5ms @ repo/issue.go:1122(repo.ViewIssue) > This pull request is broken due to missing fork information Now that I can reproduce, I will debug it

GiteaMirror commented

@amvasilyev commented on GitHub (Aug 11, 2022):

In our situation every PR is broken when a new commit is pushed to the tracking branch.

The default policy for broken repositories is to make a rebase when accepting changes from the request.

Is it worth to try to use the binary directly instead of the Docker?

@amvasilyev commented on GitHub (Aug 11, 2022): In our situation every PR is broken when a new commit is pushed to the tracking branch. The default policy for broken repositories is to make a rebase when accepting changes from the request. Is it worth to try to use the binary directly instead of the Docker?

GiteaMirror commented

@99rgosse commented on GitHub (Aug 11, 2022):

In our situation every PR is broken when a new commit is pushed to the tracking branch.

The default policy for broken repositories is to make a rebase when accepting changes from the request.

Is it worth to try to use the binary directly instead of the Docker?

the docker is made from the official binary, this won't change.

Could you please confirm that your PR that are failing came from a fork ? As the bug I was able to reproduce ??
The error message I get is from here https://github.com/go-gitea/gitea/blob/release/v1.17/services/repository/push.go#L164

@99rgosse commented on GitHub (Aug 11, 2022): > In our situation every PR is broken when a new commit is pushed to the tracking branch. > > The default policy for broken repositories is to make a rebase when accepting changes from the request. > > Is it worth to try to use the binary directly instead of the Docker? the docker is made from the official binary, this won't change. Could you please confirm that your PR that are failing came from a fork ? As the bug I was able to reproduce ?? The error message I get is from here https://github.com/go-gitea/gitea/blob/release/v1.17/services/repository/push.go#L164

GiteaMirror commented

@amvasilyev commented on GitHub (Aug 11, 2022):

Could you please confirm that your PR that are failing came from a fork ?

No. For the test purposes I have created a test a brand new repository. The whole commit tree is here:

commit 9f6518bde4cbea0309d5c4de58725e9241ab90c1 (HEAD -> prtest, origin/prtest)
    Add more data

commit e220345deee07ff4d04193429ffef2ea43c98cc7
    Add more info

commit 4a57372e8a391033b315861e72786cf7e61c280c
    Add some commit

commit 11a06d09e017a82e17e192045d2bb1818b01d4ea (origin/main, main)
    first commit

After the first commit, I have created a prtest branch. From that branch the PR to the same repository has been opened. When I have pushed the third commit, the PR moved to the broken state.

After grepping the logs of gitea I do not see the message with the gitRepo.GetCommit message, i.e.:

$ docker container logs gitea | grep GetCommit
$

the docker is made from the official binary, this won't change.

The change would be the removal of the Docker layer. The idea is from this comment:

please check your docker version. 1.17 is running alpine > 3.13 https://github.com/go-gitea/gitea/pull/18500 and docker versions less than 20.10.6 will break with hooks not running.

I also carefully reread the original issue and in my case the issue is not the same, but resulting state is the same.

@amvasilyev commented on GitHub (Aug 11, 2022): > Could you please confirm that your PR that are failing came from a fork ? No. For the test purposes I have created a test a brand new repository. The whole commit tree is here: ``` commit 9f6518bde4cbea0309d5c4de58725e9241ab90c1 (HEAD -> prtest, origin/prtest) Add more data commit e220345deee07ff4d04193429ffef2ea43c98cc7 Add more info commit 4a57372e8a391033b315861e72786cf7e61c280c Add some commit commit 11a06d09e017a82e17e192045d2bb1818b01d4ea (origin/main, main) first commit ``` After the first commit, I have created a `prtest` branch. From that branch the PR to the same repository has been opened. When I have pushed the third commit, the PR moved to the broken state. After grepping the logs of gitea I do not see the message with the `gitRepo.GetCommit` message, i.e.: ``` $ docker container logs gitea | grep GetCommit $ ``` > the docker is made from the official binary, this won't change. The change would be the removal of the Docker layer. The idea is from this comment: > please check your docker version. 1.17 is running alpine > 3.13 https://github.com/go-gitea/gitea/pull/18500 and docker versions less than 20.10.6 will break with hooks not running. I also carefully reread the original issue and in my case the issue is not the same, but resulting state is the same.

GiteaMirror commented

@amvasilyev commented on GitHub (Aug 11, 2022):

I have set up the temporary instance of gitea 1.17.0 running inside the docker container. The issue was reproduced in this environment too. Therefore there is minor chance that the issue came alongside with the migration.

Then in this additional installation I have swapped the docker image with the native binary. In this setup the issue is gone. Therefore the source of my issue is the old version of docker runtime.

@amvasilyev commented on GitHub (Aug 11, 2022): I have set up the temporary instance of gitea 1.17.0 running inside the docker container. The issue was reproduced in this environment too. Therefore there is minor chance that the issue came alongside with the migration. Then in this additional installation I have swapped the docker image with the native binary. In this setup the issue is gone. Therefore the source of my issue is the old version of docker runtime.

GiteaMirror commented

@99rgosse commented on GitHub (Aug 12, 2022):

Back to the fork problem I dug up this https://github.com/go-gitea/gitea/blob/release/v1.17/routers/web/repo/pull.go#L563

if pull.HeadRepo == nil || !headBranchExist || headBranchSha != sha { ctx.Data["IsPullRequestBroken"] = true

Conditions I have is that headBranchSha != sha because the fork was made with signed commits

"Updating by rebase" will then rebase the commits on top of master, but as it is a Gitea commits side operation, commits are not signed anymore, thus they have not the same SHA.

@lunny / @zeripath I would like to help work on a PR for this issue, could you please tell me your opinion ?
I have not yet figured out how to check this behavior. Maybe with a git diff between unsigned & signed, then accept that the SHA are different, even if not signed ?
Or completely remove possibility to do this from gitea side when you have signed commits ? (Github does not do this rebasing feature I think)

@99rgosse commented on GitHub (Aug 12, 2022): Back to the fork problem I dug up this https://github.com/go-gitea/gitea/blob/release/v1.17/routers/web/repo/pull.go#L563 ` if pull.HeadRepo == nil || !headBranchExist || headBranchSha != sha { ctx.Data["IsPullRequestBroken"] = true` Conditions I have is that headBranchSha != sha because the fork was made with **signed commits** "Updating by rebase" will then rebase the commits on top of master, but as it is a **Gitea commits** side operation, commits are **not signed anymore**, thus they have not the same SHA. @lunny / @zeripath I would like to help work on a PR for this issue, could you please tell me your opinion ? I have not yet figured out how to check this behavior. Maybe with a git diff between unsigned & signed, then accept that the SHA are different, even if not signed ? Or completely remove possibility to do this from gitea side when you have signed commits ? (Github does not do this rebasing feature I think)

GiteaMirror commented

@andre161292 commented on GitHub (Sep 12, 2022):

Any update on this? It's not working for me as well with Docker version 20.10.18 and Gitea 1.17.2.

Can i help out with any more information or logs?

@andre161292 commented on GitHub (Sep 12, 2022): Any update on this? It's not working for me as well with Docker version 20.10.18 and Gitea 1.17.2. Can i help out with any more information or logs?

GiteaMirror commented

@99rgosse commented on GitHub (Sep 13, 2022):

I worked out the way to update the fork without broking the PR.

Problem is still that the PR gets different commit sha's than the fork, then it fails the merging (security checking the checksums are identical) => I was not able to workaround this (no time)

My first idea would be to flash a message "Gitea cannot rebase on signed commits, please rebase manually your fork" (the Github way to do it)

If we are to allow rebasing by gitea, this would mean gitea should be able to force push to fork to make the checksums corresponds.

@99rgosse commented on GitHub (Sep 13, 2022): I worked out the way to update the fork without broking the PR. Problem is still that the PR gets different commit sha's than the fork, then it fails the merging (security checking the checksums are identical) => I was not able to workaround this (no time) My first idea would be to flash a message "Gitea cannot rebase on signed commits, please rebase manually your fork" (the Github way to do it) If we are to allow rebasing by gitea, this would mean gitea should be able to force push to fork to make the checksums corresponds.

GiteaMirror commented

@hieptuanle commented on GitHub (Oct 8, 2022):

Upgrading Docker Engine version from 19 to 20.10.18 fixed the issue for me.

@hieptuanle commented on GitHub (Oct 8, 2022): Upgrading Docker Engine version from 19 to 20.10.18 fixed the issue for me.

GiteaMirror commented

See https://github.com/go-gitea/gitea/pull/18050

@zeripath commented on GitHub (Oct 8, 2022):

Ah so this is YET another duplicate of: https://github.com/go-gitea/gitea/issues/16428, https://github.com/go-gitea/gitea/pull/16451, https://github.com/go-gitea/gitea/pull/16170, https://github.com/go-gitea/gitea/issues/16464, https://github.com/go-gitea/gitea/issues/16484

We put a huge warning in to tell people to upgrade their dockers for 1.17.

@zeripath commented on GitHub (Oct 8, 2022): Ah so this is YET another duplicate of: https://github.com/go-gitea/gitea/issues/16428, https://github.com/go-gitea/gitea/pull/16451, https://github.com/go-gitea/gitea/pull/16170, https://github.com/go-gitea/gitea/issues/16464, https://github.com/go-gitea/gitea/issues/16484 See https://github.com/go-gitea/gitea/pull/18050 We put a huge warning in to tell people to upgrade their dockers for 1.17.

GiteaMirror commented

@zeripath commented on GitHub (Oct 8, 2022):

@99rgosse I don't understand your comment or how it's being reproduced.

@zeripath commented on GitHub (Oct 8, 2022): @99rgosse I don't understand your comment or how it's being reproduced.

GiteaMirror commented

@lunny commented on GitHub (Oct 25, 2022):

The bug could be reproduced when click the update branch by rebase in pull request UI.

@lunny commented on GitHub (Oct 25, 2022): The bug could be reproduced when click the `update branch by rebase` in pull request UI. ![boxcnBDGDfvY0J0AzklizcJtkBf](https://user-images.githubusercontent.com/81045/197823139-d11258b6-4dff-40b4-9eda-4d64235c9439.png)

GiteaMirror commented

@lunny commented on GitHub (Oct 25, 2022):

related #16125

@lunny commented on GitHub (Oct 25, 2022): related #16125

GiteaMirror commented

@zeripath commented on GitHub (Oct 26, 2022):

The bug could be reproduced when click the update branch by rebase in pull request UI.

~~AHA!~~

~~That is the information I needed.~~

~~I bet this update is not updating the PR heads~~

Nope that should still be happening and it is doing the correct thing on my test instance.

@zeripath commented on GitHub (Oct 26, 2022): > The bug could be reproduced when click the `update branch by rebase` in pull request UI. ~~AHA!~~ ~~That is the information I needed.~~ ~~I bet this update is not updating the PR heads~~ Nope that should still be happening and it is doing the correct thing on my test instance.

GiteaMirror commented

8430f738e2/services/pull/update.go (L68-L74)

@zeripath commented on GitHub (Oct 26, 2022):

~~Right... ~~

~~So the problem is likely:~~

This ~~does not~~ directly causes an update the head refs which should also be being done as part of the post-receive hook.

~~Now... I don't understand why this defer is there because when the post-receive hook is run then that is when the PR should be updated.~~

~~So either: ~~

* This whole defer should be removed.
* OR it needs to do the update of the PR heads.

Looking a bit closer this should still cause an update of the ref head so I still don't understand and I still cannot reproduce this.

@zeripath commented on GitHub (Oct 26, 2022): ~~Right... ~~ ~~So the problem is likely:~~ https://github.com/go-gitea/gitea/blob/8430f738e296cd82f318744e2a9ddf74be27c353/services/pull/update.go#L68-L74 This ~~does not~~ directly causes an update the head refs which should also be being done as part of the post-receive hook. ~~Now... I don't understand why this defer is there because when the post-receive hook is run then that is when the PR should be updated.~~ ~~So either: ~~ ~~* This whole defer should be removed.~~ ~~* OR it needs to do the update of the PR heads.~~ Looking a bit closer this should still cause an update of the ref head so I still don't understand and I still cannot reproduce this.

GiteaMirror commented

2025-11-02 08:11:24 -06:00

@zeripath commented on GitHub (Oct 26, 2022):

Right we need some logs.

Please add tracing logs for services/pull:

[log]
MODE=..., traceconsole
...

[log.traceconsole]
LEVEL=TRACE
MODE=console
EXPRESSION=services/pull

Then reproduce the issue following a rebase and give me the logs.

That way at least I'll be able to see something.

@zeripath commented on GitHub (Oct 26, 2022): Right we need some logs. Please add tracing logs for `services/pull`: ```ini [log] MODE=..., traceconsole ... [log.traceconsole] LEVEL=TRACE MODE=console EXPRESSION=services/pull ``` Then reproduce the issue following a rebase and give me the logs. That way at least I'll be able to see something.

GiteaMirror commented

@zeripath commented on GitHub (Oct 26, 2022):

The bug could be reproduced when click the update branch by rebase in pull request UI.

I cannot reproduce this.

From my above review this is almost certainly related to issues from docker not running hooks and is a duplicate of the many reports of that issue.

If anyone can reproduce - please give us logs.

@zeripath commented on GitHub (Oct 26, 2022): > > The bug could be reproduced when click the `update branch by rebase` in pull request UI. I cannot reproduce this. From my above review this is almost certainly related to issues from docker not running hooks and is a duplicate of the many reports of that issue. If anyone can reproduce - please give us logs.

GiteaMirror commented

2025-11-02 08:11:24 -06:00

@lunny commented on GitHub (Oct 27, 2022):

The bug could be reproduced when click the update branch by rebase in pull request UI.

I cannot reproduce this.

From my above review this is almost certainly related to issues from docker not running hooks and is a duplicate of the many reports of that issue.

If anyone can reproduce - please give us logs.

It could be reproduced from a Gitea instance which upgraded from v1.15. The PR created in version v1.15, after upgraded, click the button may cause this problem. The gitea instance running with systemd

@lunny commented on GitHub (Oct 27, 2022): > > > The bug could be reproduced when click the `update branch by rebase` in pull request UI. > > I cannot reproduce this. > > From my above review this is almost certainly related to issues from docker not running hooks and is a duplicate of the many reports of that issue. > > If anyone can reproduce - please give us logs. It could be reproduced from a Gitea instance which upgraded from v1.15. The PR created in version v1.15, after upgraded, click the button may cause this problem. The gitea instance running with systemd

GiteaMirror commented

@99rgosse commented on GitHub (Oct 27, 2022):

Nota : upgrading to 1.17.3 leads to no more PR Broken for me

I'm not sure my use case is the same as others.
The most secure way for me to reproduce is to have :

1 user with signed commits pushing an outdated code and doing a PR
When creating the PR, Gitea will say that the branch is out of date, and needs a rebasing (Clicking on Update by rebase button)
Then gitea will replay the history of the master branch to the outdated branch => the commits won't be signed anymore

as you can see, now the PR is not broken in the end, in the past, this check in https://github.com/go-gitea/gitea/blob/release/v1.17/routers/web/repo/pull.go#L563 was generating the PR is broken parameter

@99rgosse commented on GitHub (Oct 27, 2022): Nota : upgrading to 1.17.3 leads to no more PR Broken for me -------------------------------- I'm not sure my use case is the same as others. The most secure way for me to reproduce is to have : - 1 user with *signed commits* pushing an outdated code and doing a PR - When creating the PR, Gitea will say that the branch is out of date, and needs a rebasing (Clicking on Update by rebase button) - Then gitea will replay the history of the master branch to the outdated branch => the commits won't be signed anymore ![image](https://user-images.githubusercontent.com/61579380/198241777-1e7629cc-13b8-4bd4-8407-24e90567d505.png) as you can see, now the PR is not broken in the end, in the past, this check in https://github.com/go-gitea/gitea/blob/release/v1.17/routers/web/repo/pull.go#L563 was generating the PR is broken parameter

GiteaMirror commented

@kutay-celebi commented on GitHub (Nov 9, 2022):

Upgrading Docker to 20.10.21 fixed my problem.

@kutay-celebi commented on GitHub (Nov 9, 2022): Upgrading Docker to 20.10.21 fixed my problem.

GiteaMirror commented

@Vylpes commented on GitHub (Dec 21, 2022):

Having this issue too - Upgrading docker didn't fix it for me

@Vylpes commented on GitHub (Dec 21, 2022): Having this issue too - Upgrading docker didn't fix it for me

GiteaMirror commented

@ghost commented on GitHub (Dec 30, 2022):

This is also reproducible by me almost every time. I can provide logs. My Gitea version is Gitea 1.19.0+dev-245-g9dcaf14a1

@ghost commented on GitHub (Dec 30, 2022): This is also reproducible by me almost every time. I can provide logs. My Gitea version is _Gitea 1.19.0+dev-245-g9dcaf14a1_

GiteaMirror commented

@lunny commented on GitHub (Dec 31, 2022):

This is also reproducible by me almost every time. I can provide logs. My Gitea version is Gitea 1.19.0+dev-245-g9dcaf14a1

Please upload the logs

@lunny commented on GitHub (Dec 31, 2022): > This is also reproducible by me almost every time. I can provide logs. My Gitea version is _Gitea 1.19.0+dev-245-g9dcaf14a1_ Please upload the logs

GiteaMirror commented

@ghost commented on GitHub (Jan 1, 2023):

@lunny Sure, here are the logs as provided by my instance admin. (We use docker too)
gitea-prrebaselog.txt

@ghost commented on GitHub (Jan 1, 2023): @lunny Sure, here are the logs as provided by my instance admin. (We use docker too) [gitea-prrebaselog.txt](https://github.com/go-gitea/gitea/files/10329383/gitea-prrebaselog.txt)

GiteaMirror commented

good_gitea_pr_rebase_log_postgresql.txt
good_gitea_pr_rebase_log_sqlite3.txt

@ghost commented on GitHub (Jan 2, 2023):

Okay, I managed to reproduce the same bug on a self hosted instance of mine. It's using Gitea 1.18.0, The docker version is 20.10.5+dfsg1, build 55c4c88. I have managed to reproduce the bug on both postgresql and sqlite3 databases. Logs attached here:

I can also give you some more additional information:

Issue still occurs when no commits are signed
To reproduce:
1. Create an organization
2. Create a repo in that organization
3. Fork the repo
4. Make a change in the repo and open a PR
5. Push some change to the original organization repo
6. Go to the PR and hit the "update by rebase" option
7. PR broken due to missing fork information

(This steps worked for me 100% of times both on my self-hosted instance and the other instance)

I have also realized that it's not needed to fork the repo to create this issue, for example, just creating a new branch on the original repo and following the steps from four onwards is enough to trigger the bug as well.

@ghost commented on GitHub (Jan 2, 2023): Okay, I managed to reproduce the same bug on a self hosted instance of mine. It's using _Gitea 1.18.0_, The docker version is `20.10.5+dfsg1, build 55c4c88`. I have managed to reproduce the bug on both postgresql and sqlite3 databases. Logs attached here: [good_gitea_pr_rebase_log_postgresql.txt](https://github.com/go-gitea/gitea/files/10332202/good_gitea_pr_rebase_log_postgresql.txt) [good_gitea_pr_rebase_log_sqlite3.txt](https://github.com/go-gitea/gitea/files/10332203/good_gitea_pr_rebase_log_sqlite3.txt) I can also give you some more additional information: - Issue still occurs when no commits are signed - To reproduce: 1. Create an organization 2. Create a repo in that organization 3. Fork the repo 4. Make a change in the repo and open a PR 5. Push some change to the original organization repo 6. Go to the PR and hit the "update by rebase" option 7. PR broken due to missing fork information _(This steps worked for me 100% of times both on my self-hosted instance and the [other instance](https://git.anonymousland.org))_ I have also realized that it's not needed to fork the repo to create this issue, for example, just creating a new branch on the original repo and following the steps from four onwards is enough to trigger the bug as well.

GiteaMirror commented

@zekexiao commented on GitHub (Jan 11, 2023):

Same in 1.17.3, organization repo branches cannot RP.

workaround: push to a personal frok repo, then PR.

@zekexiao commented on GitHub (Jan 11, 2023): Same in 1.17.3, organization repo branches cannot RP. workaround: push to a personal frok repo, then PR.

GiteaMirror commented

2025-11-02 08:11:27 -06:00

@MHOOO commented on GitHub (Jan 15, 2023):

Same for me. Gitea 1.17.4. It worked for a while, but suddenly stopped. The repository was public when the error first appeared. Since then, I've tried to make it private, as well as putting it into an organization. None of that worked.

@MHOOO commented on GitHub (Jan 15, 2023): Same for me. Gitea 1.17.4. It worked for a while, but suddenly stopped. The repository was public when the error first appeared. Since then, I've tried to make it private, as well as putting it into an organization. None of that worked.

GiteaMirror commented

@zeripath commented on GitHub (Jan 18, 2023):

Thank you @NebulaOrion that is the information needed for me to figure out what is happening.

The problem is:

vi. Go to the PR and hit the "update by rebase" option

The code that does this doesn't correctly update the head branch.

I believe that:

aa87b36900/services/pull/merge.go (L609)

is the faulty line -- the question is what is the correct push here. Likely it should be a push to the original head but then we need to get a second push to occur updating the git pr head.

@zeripath commented on GitHub (Jan 18, 2023): Thank you @NebulaOrion that is the information needed for me to figure out what is happening. The problem is: > vi. Go to the PR and hit the "update by rebase" option The code that does this doesn't correctly update the head branch. I believe that: https://github.com/go-gitea/gitea/blob/aa87b3690081261379c6b93488cdd3f3f7b1ef31/services/pull/merge.go#L609 is the faulty line -- the question is what is the correct push here. Likely it should be a push to the original head but then we need to get a second push to occur updating the git pr head.

GiteaMirror commented

2025-11-02 08:11:27 -06:00

@zeripath commented on GitHub (Jan 19, 2023):

~~hmm... I wonder if this is actually an issue with force-pushes in general.~~ Nope.

~~I suspect it's a bug in pushUpdates~~

No it's in the pushing environment!

@zeripath commented on GitHub (Jan 19, 2023): ~~hmm... I wonder if this is actually an issue with force-pushes in general.~~ Nope. ~~I suspect it's a bug in `pushUpdates`~~ No it's in the pushing environment!

GiteaMirror commented

@Vylpes commented on GitHub (Jan 20, 2023):

Still getting this error on 1.18.2 when merging in changes because the PR was outdated

@Vylpes commented on GitHub (Jan 20, 2023): Still getting this error on 1.18.2 when merging in changes because the PR was outdated <img width="649" alt="image" src="https://user-images.githubusercontent.com/8274970/213776121-84445e30-4b13-4890-977c-f89d9ae7d9df.png">

GiteaMirror commented

@zeripath commented on GitHub (Jan 21, 2023):

@Vylpes please could you explain how you reproduce the error, because I cannot reproduce on main or on 1.18.2.

@zeripath commented on GitHub (Jan 21, 2023): @Vylpes please could you explain how you reproduce the error, because I cannot reproduce on main or on 1.18.2.

GiteaMirror commented

@delvh commented on GitHub (Jan 21, 2023):

Hmm, I just noticed that the fix can only be part of the solution:
The solution works for repos that have forks that send PRs.
I think I've seen this message on PRs in a repo that doesn't have forks.
So, perhaps, there is a part two to this problem?
(However, that was around 1.14 or so, so I don't know if this is still relevant)

@delvh commented on GitHub (Jan 21, 2023): Hmm, I just noticed that the fix can only be part of the solution: The solution works for repos that have forks that send PRs. I think I've seen this message on PRs in a repo that doesn't have forks. So, perhaps, there is a part two to this problem? (However, that was around 1.14 or so, so I don't know if this is still relevant)

GiteaMirror commented

@MHOOO commented on GitHub (Jan 21, 2023):

In my case the repository is definitely not a fork, yet I'm still having
this issue

delvh @.***> schrieb am Sa., 21. Jan. 2023, 14:33:

Hmm, I just noticed that the fix can only be part of the solution:
The solution works for repos that have forks that send PRs.
I think I've seen this message on PRs in a repo that doesn't have forks.
So, perhaps, there is a part two to this problem?

—
Reply to this email directly, view it on GitHub
https://github.com/go-gitea/gitea/issues/18802#issuecomment-1399252686,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACIMCHVKL7D6MSZJL457WLWTPQUPANCNFSM5OXEDGAA
.
You are receiving this because you commented.Message ID:
@.***>

@MHOOO commented on GitHub (Jan 21, 2023): In my case the repository is definitely not a fork, yet I'm still having this issue delvh ***@***.***> schrieb am Sa., 21. Jan. 2023, 14:33: > Hmm, I just noticed that the fix can only be part of the solution: > The solution works for repos that have forks that send PRs. > I think I've seen this message on PRs in a repo that doesn't have forks. > So, perhaps, there is a part two to this problem? > > — > Reply to this email directly, view it on GitHub > <https://github.com/go-gitea/gitea/issues/18802#issuecomment-1399252686>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACIMCHVKL7D6MSZJL457WLWTPQUPANCNFSM5OXEDGAA> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

GiteaMirror commented

@Vylpes commented on GitHub (Jan 21, 2023):

@zeripath Pretty much all I did was:

have a PR created, update the base branch (making the PR out of date)
updating the PR by either the "update branch" button or by pushing to the branch

This is on an organisation repo, no forks, just from a feature/* branch to develop. I've tried PRs that were made before updating and making new PRs

@Vylpes commented on GitHub (Jan 21, 2023): @zeripath Pretty much all I did was: 1. have a PR created, update the base branch (making the PR out of date) 2. updating the PR by either the "update branch" button or by pushing to the branch This is on an organisation repo, no forks, just from a `feature/*` branch to `develop`. I've tried PRs that were made before updating and making new PRs

GiteaMirror commented

@zeripath commented on GitHub (Jan 21, 2023):

@Vylpes I cannot reproduce that on 1.18.2 or on try. (see https://try.gitea.io/testOrf/test-18802/pulls/1, https://try.gitea.io/testOrf/test-18802/pulls/2, https://try.gitea.io/testOrf/test-18802/pulls/3, https://try.gitea.io/testOrf/test-18802/pulls/4)

If your PR was broken already it will remain broken - just push an empty commit and it should resync.

@zeripath commented on GitHub (Jan 21, 2023): @Vylpes I cannot reproduce that on 1.18.2 or on try. (see https://try.gitea.io/testOrf/test-18802/pulls/1, https://try.gitea.io/testOrf/test-18802/pulls/2, https://try.gitea.io/testOrf/test-18802/pulls/3, https://try.gitea.io/testOrf/test-18802/pulls/4) If your PR was broken already it will remain broken - just push an empty commit and it should resync.

GiteaMirror commented

@Vylpes commented on GitHub (Jan 21, 2023):

@zeripath Then I have no clue why my instance is still doing it - I've pushed an empty commit and it doesn't fix it (nor does it show in the commits list in the PR).

Is there anything I can give you other than that to help? Or is there a way I can "reset" my instance without losing repo data?

@Vylpes commented on GitHub (Jan 21, 2023): @zeripath Then I have no clue why my instance is still doing it - I've pushed an empty commit and it doesn't fix it (nor does it show in the commits list in the PR). Is there anything I can give you other than that to help? Or is there a way I can "reset" my instance without losing repo data?

GiteaMirror commented