3 ms·
A PR with merges is fine by me, it lets me see how the PR has evolved. What I want is for GitHub to track changes between sets of commits in a PR so that you c
by spankalee 3y ago
A PR with merges is fine by me, it lets me see how the PR has evolved.
What I want is for GitHub to track changes between sets of commits in a PR so that you can do most of the review with merges and "address review comments" commits, and then rebase into well organized, logical commits and review that those have the same diff as the messy history after a force push.
- adhesive_wombat 3y agoAt least Gitlab does that when you push a new commit (force or not) to the branch: it'll show a list of value of the branch head commit and you can diff between them.
- smw 3y agoSo does Github, but it breaks if you fix via rebase and push -f. Gerrit and some other competitors manage this better.
- richbell 3y agoThe problem is PRs that have <5 lines of changes followed by dozens of pointless merges, because users are prompted to merge every time another PR is merged. It wouldn't be a problem if people took the time to organize the history prior to merging as you said, but most people don't do this.