docs/GitHub: Add note about force-pushing when rebasing on main

[mehdi_amini]

llvm/docs/GitHub.rst

40

Is this an opportunity to squash? Does GitHub preserve better the history if we force-push on rebase but don't squash?

The issue with this way of adding "fix up" commits is that a conflict during rebase may lead to as many redundant manual conflict resolution as there are "fix up" commits.

[jhenderson]

llvm/docs/GitHub.rst

40

Force pushes being unavoidable when doing rebases is one of the reasons I have a dislike of reviewing on GitHub, due to the issues it has.

Regarding the additional sentence itself, I'm fine with it. I don't know of a way that will improve comment history more than anything else (squashing probably is safe, and I have no objection to encouraging it as per @mehdi_amini's comment). That being said, I haven't done any rigorous testing.

[mehdi_amini]

llvm/docs/GitHub.rst

40

Technically one would want to squash first, and rebase after! (to avoid the multiple conflicts resolution)

There is also the option of merging main back into the user branch instead of force-pushing: why not this?

[jhenderson]

llvm/docs/GitHub.rst

40

There is also the option of merging main back into the user branch instead of force-pushing: why not this?

Doesn't that require a merge commit? I'm pretty sure we don't want those in our main branch history, and I don't know how that then plays with the squash & merge button at the end.

[mehdi_amini]

llvm/docs/GitHub.rst

40

With squash&merge and our branch protection, we can guarantee that main will end up with a single fast-forward commit, so it shouldn't matter there.

[mehdi_amini]

Ping on this? Merge main into the development branch or rebase?

[ldionne]

IMO the new sentence makes sense and we should just ship this.

[ldionne]

Gentle ping on this. Let's either abandon this or merge it to clear up the review queue.

llvm/docs/GitHub.rst

 ^^^^^^^^^^^^^^^^^^^^^^
 For pull requests, please push a branch to your fork of the llvm-project and
 `create a pull request from the fork <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork>`_.
 
 Updating Pull Requests
 ^^^^^^^^^^^^^^^^^^^^^^
 When updating a pull request, you should push additional "fix up" commits to
 your branch instead of force pushing.  This makes it easier for GitHub to
-track the context of previous review comments.
+track the context of previous review comments.  However, if you are rebasing
+your changes on the latest main branch, then your only option is to force push.
 
 If you do this, you must squash and merge before committing and
 you must use the pull request title and description as the commit message.
 The default commit message for a squashed pull request is the pull request
 description, so this will allow reviewers to review the commit message before
 approving the commit.
 
 Releases