Hacker News new | ask | show | jobs
by chrisfosterelli 1391 days ago
What happened here (if I understand right) is:

* septicmk forked v6d-io/v6d to septicmk/v6d

* septicmk added commits to septicmk/v6d:main

* septicmk created a pull request from septicmk/v6d:main to v6d-io/v6d:main

* septicmk force pushed septicmk/v6d:main with the head commit of v6d-io/v6d:main

* Github closed the pull request and displayed a "merge" notification

The UX issue is that septicmk did not have write permission to v6d-io and did not actually merge any commit into it, but GitHub says "septicmk merged commit 61f3741 into v6d-io:main". Commit 61f3741 was authored by sighingnow and was already on v6d-io:main.

So in this case no authorized merge actually happened, the PR was just updated to have no difference from the actual repository's main branch, but GitHub makes it seem like a merge happened.
1 comments
dnsmichi 1391 days ago
GitLab team member here. It seems related to the problem that you cannot open an empty PR https://stackoverflow.com/questions/46577500/why-cant-i-crea... and force overriding an old branch base is a workaround to land at an empty diff. Another workaround could be git commit —-allow-empty, making the GitHub UI think that no changes between branches is equal to the merged state.

The behavior is not reproducible in GitLab, where empty merge requests can be created, and remain in the open state, also with zero changes at some later point. Added in GitLab 9.2 as part of the issue to new branch and wip/draft merge request flow: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28558

link
chrisfosterelli 1390 days ago
I think that Gitlab behaviour makes more intuitive sense. Thanks for chiming in.
link
sighingnow 1390 days ago
Allowing "zero changes" state for a merge request does make sense, as during the development workflow developers may doing some rebase & force push work and they may forget commit changes after reset to main and before push to the pull requests.

Closing the "zero changes" merge request have confused in my previous experience when I continue to push re-added commits to the original pull request branch.

link