Branch/commit ref mixup in PRs with weird side effects

[ashimokawa]

• Gitea version (or commit ref): 1.11-rc2
• Git version: 2.20.1
• Operating system: Debian 10
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No (hard to reproduce)
  • Not relevant
• Log gist:

Description

I merged this PR by rebasing :
https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/1785

(there was a duplicate message, that two people closed the PR, but that's probably unrelated)

Then there was

https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/1788

which was all of a sudden pointing to the commit from 1785 mentioned above.
You can still see the effect now when following the link to 1788, it points to the same commit "merged in ...." like 1785 which is wrong (but the branch mentioned at the top is correct). It also says that the guy who opened 1785 closed 1788 which is - wrong. Both PRs where by different people and completely unrelated. Scary....

Any idea?

[ashimokawa]

This might be describing two different issues, but similar to
https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/1785
(where two people seemingly merged)

In the following issue:
https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/1782
An organization(!) is mentioned as the closing person. In addition to my username.
All I did is pressing the merge and rebase button. At that time codeberg.org was running gitea 1.10, the mixup I describe happened while running 1.11.

In any case, the effect that branches got mixed up in PRs is the main concern in this issue.
And I wonder if this would also have happened if I chose merge (without rebase). All the PRs.

Is there anything I could lookup in the database regarding the mixed up PRs (1785 and 1788) to help debugging the issue?

[lunny]

When deleting a branch it will try to close the pull request. It should check if the pull request has been merged or closed.

[ashimokawa]

@lunny
Branches have been deleted after merging the PRs. Deletion of branches did not trigger this.
The messed PR seem to have pointed to the wrong commit ref out of nowhere.

@TaaviE
What was the fist effect you saw when you realized your PR was broken? Did you delete your branch before that?

[TaaviE]

I didn't delete my branch, just pushed a commit to replace the existing one in the PR.

[ashimokawa]

@TaaviE
So you force pushed to the branch with the PR, and then it got mixed up with the other PR?

@lunny
@lafriks
Cound that be a problem? Force pushing to a PR branch?

[zeripath]

yup force pushing to a PR branch making it align with the base branch would cause gitea to think it has been merged. (Yeah that sounds odd but if you want to allow merging of PRs by hand that's how you do it - well not quite - but that's how unkwon did it...)

[TaaviE]

Wouldn't it make sense not to claim the PR has been merged? Rather claim it's closed and by being equal to master, a system message. Currently it rather confusingly just sent e-mails of people doing things they haven't. I personally would get a heart attack, thinking my account got somehow compromised.

[zeripath]

Yes. It would. I have an idea for how to do this properly but I haven't had a chance to do it.

[ashimokawa]

@zeripath
But not only that the PR got set to merged - it is completely messed up/mixed up with another PR.
Also mpst PRs that I regularly rebase+merged via the GUI got a double close from two different users (one even from an organzation), that's completely scary.

[vanger-pro]

If you click commit, with an existing PR, the PR indicates that the branch was deleted. (This pull request cannot be reopened because the branch was deleted.) Although the branch currently exists.