Enabled "Always suggest updating pull request branches" option

[JelleZijlstra]

FYI, I enabled the "Always suggest updating pull request branches" option in this repo's settings. See python/core-workflow#434 for context on this option.

I'll close this issue in a few days.

[JelleZijlstra]

And if anyone has concerns about this change let me know and we can discuss undoing it.

[Rosuav]

From my understanding, it's just creating an option, so there's no risk of it accidentally breaking stuff. 👍

[CAM-Gerlach]

I played around with it on #2484 ; at least at a high level, having it as an option for authors and maintainers, and ensuring that both methods are available, seems like a fairly safe win. I'd probably only use it myself on my PRs that were ready to merge, since otherwise it doesn't really save any time over hub sync && git rebase main since I'd have to do git pull && git reset --hard FETCH_HEAD, and both remember to pull before making changes (never mind if I was in the middle of such), which I already try to routinely do in case of applied suggestions, and more importantly pay careful attention to the pull output (or always check git log --graph after) to check whether I need to git reset to elide any resulting spurious merges created on my end.

I do have a couple potential worries. It does make it easier for PR authors to spam merges, making the PR commit history more difficult to navigate, though that's much less of a concern on other people's PRs with squash merges, mostly interacting with it through GitHub's UI, and the commit hygiene of many contributors already, so I don't see it as much of a real concern. I'd also think there could be some potential friction with maintainers updating PR authors' branches while they are working on things locally, or when they neglect to pull, or using a method (merge or rebase) that's not part of the author's standard workflow, but since there's relatively few of us, I'm sure we can figure that out fairly efficiently between ourselves.