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

[sinh927]

• 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?

[guillep2k]

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.

[meaz]

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

[zeripath]

@meaz I can't reproduce on master.

What version are you reporting this on?

[zeripath]

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

[meaz]

It is version 1.11.4.

[zeripath]

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

[meaz]

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.

[zeripath]

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.

[meaz]

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?

[DefinitelyADev]

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.

[meaz]

The admin updated his instance, it works now.