If you push to a branch in a pull request, it will be "fork deleted". #5295

New Issue

GiteaMirror · 2025-11-02T06:20:40-06:00

GiteaMirror commented

2025-11-02 06:20:40 -06:00

Originally created by @sinh927 on GitHub (Apr 23, 2020).

Gitea version (or commit ref):gitea-1.11.4-linux-amd64
Git version:2.24.0
Operating system:CentOS Linux release 7.6.1810 (Core)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

I used gitea-1.9.2 to begin with. There was no problem at the time.
We then moved to gitea-1.10.1,1.10.2. It was working too.
However, after moving to gitea-1.11.1, an additional push to a branch in a pull request resulted in fork deleted and the pull request could no longer be merged.
The next time I reverted to gitea-1.10.4 and gitea-1.10.6, it worked.
But the next time I select gitea-1.11.4, it's the same error.
How can I get rid of this error?

Originally created by @sinh927 on GitHub (Apr 23, 2020). - Gitea version (or commit ref):gitea-1.11.4-linux-amd64 - Git version:2.24.0 - Operating system:CentOS Linux release 7.6.1810 (Core) - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description I used gitea-1.9.2 to begin with. There was no problem at the time. We then moved to gitea-1.10.1,1.10.2. It was working too. However, after moving to gitea-1.11.1, an additional push to a branch in a pull request resulted in fork deleted and the pull request could no longer be merged. The next time I reverted to gitea-1.10.4 and gitea-1.10.6, it worked. But the next time I select gitea-1.11.4, it's the same error. How can I get rid of this error?

GiteaMirror added the issue/needs-feedback label 2025-11-02 06:20:40 -06:00

GiteaMirror closed this issue

2025-11-02 06:20:41 -06:00

GiteaMirror commented

2025-11-02 06:20:41 -06:00

@guillep2k commented on GitHub (Apr 25, 2020):

Is it possible that you ran gitea with different file names or different file paths (you shouldn't)? (e.g. gitea-1.11 instead of gitea, or /bin/gitea1.11/gitea vs. /bin/gitea1.10/gitea). If that's the case, make sure to run the "rebuild git hooks" procedure from the site admin menu, but try to avoid renaming the executable. Also, make sure you never access the gitea repositories directly: only through gitea (or your local copies, of course).

By the way, it's not advisable to go back and forth with the versions, because the database suffers changes on each migration that may not be backwards compatible.

@guillep2k commented on GitHub (Apr 25, 2020): Is it possible that you ran gitea with different file names or different file paths (you shouldn't)? (e.g. `gitea-1.11` instead of `gitea`, or `/bin/gitea1.11/gitea` vs. `/bin/gitea1.10/gitea`). If that's the case, make sure to run the "rebuild git hooks" procedure from the site admin menu, but try to avoid renaming the executable. Also, make sure you never access the gitea repositories directly: only through gitea (or your local copies, of course). By the way, it's not advisable to go back and forth with the versions, because the database suffers changes on each migration that may not be backwards compatible.

GiteaMirror commented

2025-11-02 06:20:41 -06:00

@meaz commented on GitHub (May 5, 2020):

I have an issue that looks the same, even though I have this error in a different way.

Here is what I do:

I create a branch, push to it.
I do a pull request
I push new things into the same branch

When I do that, I get this message in my Pull request: This pull request is broken due to missing fork information.

And meaz wants to merge 1 commits from mybranch into master becomes meaz wants to merge 1 commits from deleted into master

@meaz commented on GitHub (May 5, 2020): I have an issue that looks the same, even though I have this error in a different way. Here is what I do: - I create a branch, push to it. - I do a pull request - I push new things into the same branch When I do that, I get this message in my Pull request: ` This pull request is broken due to missing fork information. ` And `meaz wants to merge 1 commits from mybranch into master` becomes `meaz wants to merge 1 commits from deleted into master`

GiteaMirror commented

2025-11-02 06:20:42 -06:00

@zeripath commented on GitHub (May 5, 2020):

@meaz I can't reproduce on master.

What version are you reporting this on?

@zeripath commented on GitHub (May 5, 2020): @meaz I can't reproduce on master. What version are you reporting this on?

GiteaMirror commented

2025-11-02 06:20:42 -06:00

@zeripath commented on GitHub (May 5, 2020):

I also can't reproduce on release/v1.11 or 1.11.4..

@zeripath commented on GitHub (May 5, 2020): I also can't reproduce on release/v1.11 or 1.11.4..

GiteaMirror commented

2025-11-02 06:20:42 -06:00

@meaz commented on GitHub (May 6, 2020):

It is version 1.11.4.

@meaz commented on GitHub (May 6, 2020): It is version 1.11.4.

GiteaMirror commented

2025-11-02 06:20:42 -06:00

@zeripath commented on GitHub (May 6, 2020):

Ok I tried to reproduce on 1.11.4 but couldn't. Can you reproduce on try?

Can you give me an exact script to reproduce on 1.11.4 - (I tried to follow your comments above but was unable to reproduce with those - but I missed your info about fork because you didn't mention fork in your steps to reproduce.)

Is the problem unpredictable - in that it only occurs infrequently?

Does it rely on load? What OS are you running on? What DB?

Ah looking again I see that you report fork broken - Are you pushing to branch on a fork which has an open pr to its base repo?

I will try testing that.

Doesn't seem to be broken on forks with try.gitea.io still need to check force pushes and the 1.11s

@zeripath commented on GitHub (May 6, 2020): Ok I tried to reproduce on 1.11.4 but couldn't. Can you reproduce on try? Can you give me an exact script to reproduce on 1.11.4 - (I tried to follow your comments above but was unable to reproduce with those - but I missed your info about fork because you didn't mention fork in your steps to reproduce.) Is the problem unpredictable - in that it only occurs infrequently? Does it rely on load? What OS are you running on? What DB? Ah looking again I see that you report fork broken - Are you pushing to branch on a fork which has an open pr to its base repo? I will try testing that. --- Doesn't seem to be broken on forks with try.gitea.io still need to check force pushes and the 1.11s

GiteaMirror commented

2025-11-02 06:20:43 -06:00

@meaz commented on GitHub (May 6, 2020):

Hi,
indeed, there is no issue won try...

As for the steps:

I clone the project
I create a branch, push to it.
I do a pull request
I push new things into the same branch
The error appears.

Is the problem unpredictable - in that it only occurs infrequently?

No, it happens each time I do the same steps, and for different repos.

Does it rely on load? What OS are you running on? What DB?

I don't know, I'll ask the admin. OS I'm pretty sure it is Debian Stretch. DB is postgresql.

Are you pushing to branch on a fork which has an open pr to its base repo?

I'm not pushing to a fork. Directly to a branch on the main repo.

@meaz commented on GitHub (May 6, 2020): Hi, indeed, there is no issue won try... As for the steps: - I clone the project - I create a branch, push to it. - I do a pull request - I push new things into the same branch - The error appears. > Is the problem unpredictable - in that it only occurs infrequently? No, it happens each time I do the same steps, and for different repos. > Does it rely on load? What OS are you running on? What DB? I don't know, I'll ask the admin. OS I'm pretty sure it is Debian Stretch. DB is postgresql. > Are you pushing to branch on a fork which has an open pr to its base repo? I'm not pushing to a fork. Directly to a branch on the main repo.

GiteaMirror commented

2025-11-02 06:20:43 -06:00

@zeripath commented on GitHub (May 6, 2020):

Are you pushing over ssh or https?

If you're pushing over ssh what happens if you do a simple ssh to git@server - you should not get a prompt - if you do you are not logging into gitea with a key managed by gitea and therefore all bets are off and you are in an unsupported situation.

@zeripath commented on GitHub (May 6, 2020): Are you pushing over ssh or https? If you're pushing over ssh what happens if you do a simple ssh to git@server - you should not get a prompt - if you do you are not logging into gitea with a key managed by gitea and therefore all bets are off and you are in an unsupported situation.

GiteaMirror commented

2025-11-02 06:20:43 -06:00

@meaz commented on GitHub (May 6, 2020):

I'm pushing using Atom, so I guess it is https ?

I'll try to spot the issue more precisely with the admin. Any idea where we should start searching?

@meaz commented on GitHub (May 6, 2020): I'm pushing using Atom, so I guess it is https ? I'll try to spot the issue more precisely with the admin. Any idea where we should start searching?

GiteaMirror commented

2025-11-02 06:20:44 -06:00

@DefinitelyADev commented on GitHub (May 6, 2020):

I'm pushing using Atom, so I guess it is https ?
Atom probably uses a plugin to push?! Any plugin that does git stuff probably uses git scm in the background, which supports ssh. The way it handles the remote url happens automatically. For example you won't see any different behavior between git clone https://<url>/<owner>/<repo>.git and git@<url>:<owner>/<repo>.git. So it could be using both you should see the remote url if it has http/https or something like user@something, it should be viewable through Atom.

I'll try to spot the issue more precisely with the admin. Any idea where we should start searching?

I clone the project

I create a branch, push to it.

I do a pull request

I push new things into the same branch

The error appears.

I tried the above using a raspberry pi 3 b+, with the most recent updates and postgresql and I could not replicate the issue.

@DefinitelyADev commented on GitHub (May 6, 2020): > I'm pushing using Atom, so I guess it is https ? Atom probably uses a plugin to push?! Any plugin that does git stuff probably uses git scm in the background, which supports ssh. The way it handles the remote url happens automatically. For example you won't see any different behavior between `git clone https://<url>/<owner>/<repo>.git` and `git@<url>:<owner>/<repo>.git`. So it could be using both you should see the remote url if it has http/https or something like user@something, it should be viewable through Atom. > I'll try to spot the issue more precisely with the admin. Any idea where we should start searching? > * I clone the project > * I create a branch, push to it. > * I do a pull request > * I push new things into the same branch > * The error appears. I tried the above using a raspberry pi 3 b+, with the most recent updates and postgresql and I could not replicate the issue.

GiteaMirror commented

2025-11-02 06:20:44 -06:00

@meaz commented on GitHub (Jun 7, 2020):

The admin updated his instance, it works now.

@meaz commented on GitHub (Jun 7, 2020): The admin updated his instance, it works now.

GiteaMirror referenced this issue

2025-11-02 15:27:54 -06:00

[PR #5295] [MERGED] Fix typo in configuration #17743

Sign in to join this conversation.