Sorry for the dramatic title :-) but, if it actually happened this way, it is a pretty serious bug...
As far as I can tell, this PR:
https://pagure.io/waiverdb/pull-request/57
was at commit 68ed69ad2b23dae1305ad4df68132acaffb73e12 after a few rebases (but it was still not rebased up to the latest master). Master would have been af2709698278d0e78d7e91a1efd2a616dbfedd28. So when that PR was merged, Pagure should have created a merge commit. Instead it just updated master to 68ed69ad2b23dae1305ad4df68132acaffb73e12 directly, dropping a few commits in the process.
Could Pagure have become confused because the PR was rebased, but just not rebased onto the latest master?
(We still have the lost commits and will reconstruct master back to a good state now, so I am not worried about that. But if I am not mistaken about what happened then it seems like a serious bug.)
Btw it would be super helpful if the PR showed more than just rebased. Like ideally, what the new SHA of the rebased branch is. I guess I can file a separate RFE for that.
rebased
Okay sorry, this is not a bug. Turns out it was a force-pushing accident which happened last week which we weren't aware of.
Sorry for the noise. :-)
Metadata Update from @dcallagh: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
I'm glad this turns out not to be a bug in pagure, you had me scared here for a while :)
Sorry about that! I knew I should have dug into it more carefully before writing up the bug.