I assume that you mean:
git pull # main branch
git switch pr # timestamps are updated. Most files need to be rebuilt
git merge origin/main # resolve conflicts here
This works. However, does this make a reviewer’s life easier?
As a reviewer, I check out the branch with gh pr checkout $id. How can I see the code modified in this PR? git diff main..pr output includes all commits in the merge commit and is therefore not ideal.
I do not see how this git merge origin/main flow is better than my alternative:
The best workaround I can come up with is to: perform a rebase and force push, then make a functional change and append a new commit. The new commit represents the part that reviewers have not read.
If I invoke git log, all the updates are in the last few commits. With the git merge origin/main flow, it’s difficult to find all commits (original commit plus fixups) in this pull request.
I’d like comment on this bullet point in my original message:
The fidelity of preserving inline comments and analysis of “Outdated”. How is it problematic after a rebase or a force push? IIUC, appending a new commit without a rebase/force-push makes nearly comments outdated as well.
I feel that GitHub’s comment system is now robust enough. If we merely rebase and append a new commit, the comments are preserved with high fidelity.
Let me elaborate on git switch pr # timestamps are updated. Most files need to be rebuilt.
I often maintain multiple pending reviews. If I invoke the following commands, I need to rebuild very few files.
git rebase origin/main pr1
# edit, possibly append a new commit
git push -f --no-verify
git rebase origin/main pr2
# edit, possibly append a new commit
git push -f --no-verify
If I use the merge workflow
git switch pr1
git merge orign/main
# edit, append a new commit
git push
git switch pr2
git merge orign/main
# edit, append a new commit
git push
It’s almost assuredly CMake will rerun (since some CMake files have been modified by others) and Ninja needs to rebuild most targets.