go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.78k stars 5.47k forks source link

Branch/commit ref mixup in PRs with weird side effects #10086

Open ashimokawa opened 4 years ago

ashimokawa commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

ashimokawa commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

ashimokawa commented 4 years ago

@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 commented 4 years ago

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.