1. 5
  1. 8

    On any reasonably large project, this would send the PR author tens of emails everyday. It can take weeks for the PR to get reviewed. Why not let the reviewer / maintainer themselves update the branch (if there’s no merge conflicts)?

    GitHub also has branch protection rules which will prevent you from merging a branch that’s not up to date with master.

    1. 3

      Or just rebase when applying PRs. If you get a conflict, notify the submitter and move on.

      1. 1

        It’s going to be a problem for large teams for sure, in that case, we could optimize this to send periodic reminders (maybe once per week that your branch is X commits behind) instead of reminding for every merge. Something I haven’t given a thought about.

      2. 7

        Seems like if you run into this you might want a merge queue and as I see Github even provides one: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/using-a-merge-queue

        1. 4

          Ooh nice this looks like it may be fairly new as I’ve not seen that before. I know GitLab has had it for some time (called Merge Trains) and is convenient for this

        2. 5

          Is there a reason that you wouldn’t just use the “Require branches to be up to date before merging” option in the branch protection rules? The user will be prompted to update the branch with a button and any merge conflicts with the parent branch will be highlighted automatically. It is far less noisy than bot-driven comments.

          1. 1

            That’s pretty cool, though you only need 5 lines of configuration using Mergify to either automate the update, or at least do the same “ping author” scenarios. :)