Prefer upstream for main

[jaraco]

[hugovk]

Would this mean pushing to main would attempt to push to upstream/main?

Usually there's no need to push to main, except when syncing upstream/main to origin/main, which I think this change would make redundant?

But some people may have muscle memory, because it's a very common thing to do with forks (see all these upvotes, and "Syncing a fork" is quite high in GitHub's "Collaborating with pull requests" docs).

Another rare but occasional use case for pushing to main: wanting to test your own changes on CI when the CI is locked to only run for main and not for feature branches.

[erlend-aasland]

Would this mean pushing to main would attempt to push to upstream/main?

The devguide should be updated to show how to configure upstream push as an invalid operation. For example, by supplying an invalid URL for such an operation.

[jaraco]

Would this mean pushing to main would attempt to push to upstream/main?

Yes, it seems that's the case :(

 draft $ git clone gh://python/cpython
Cloning into 'cpython'...
remote: Enumerating objects: 911455, done.
remote: Counting objects: 100% (245/245), done.
remote: Compressing objects: 100% (163/163), done.
remote: Total 911455 (delta 145), reused 143 (delta 82), pack-reused 911210
Receiving objects: 100% (911455/911455), 497.39 MiB | 5.25 MiB/s, done.
Resolving deltas: 100% (722615/722615), done.
 draft $ cd cpython
 cpython main $ git remote -v
origin  https://github.com/python/cpython (fetch)
origin  https://github.com/python/cpython (push)
 cpython main $ gh repo fork --remote
! jaraco/cpython already exists
✓ Added remote origin
 cpython main $ git remote -v
origin  https://github.com/jaraco/cpython.git (fetch)
origin  https://github.com/jaraco/cpython.git (push)
upstream        https://github.com/python/cpython (fetch)
upstream        https://github.com/python/cpython (push)
 cpython main $ git config --local -l
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.precomposeunicode=true
remote.upstream.url=gh://python/cpython
remote.upstream.gh-resolved=base
remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
branch.main.remote=upstream
branch.main.merge=refs/heads/main
remote.origin.url=https://github.com/jaraco/cpython.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
 cpython main $ touch foo
 cpython main $ git add foo
 cpython main $ git commit -a -m "add foo"
[main 4838818fec] add foo
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 foo
 cpython main $ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 925 bytes | 71.00 KiB/s, done.
Total 3 (delta 1), reused 1 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: 7 of 7 required status checks are expected.
To https://github.com/python/cpython
 ! [remote rejected]       main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/python/cpython'

It looks like maybe the upstream 'push' can be configured to also point to the user's fork:

 cpython main $ git remote set-url --push upstream gh://jaraco/cpython
 cpython main $ git remote -v
origin  https://github.com/jaraco/cpython.git (fetch)
origin  https://github.com/jaraco/cpython.git (push)
upstream        https://github.com/python/cpython (fetch)
upstream        https://github.com/jaraco/cpython (push)
 cpython main $ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 925 bytes | 102.00 KiB/s, done.
Total 3 (delta 1), reused 1 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/jaraco/cpython
   e0d54a4a79..4838818fec  main -> main

That configuration should also address @erlend-aasland's suggestion. Instead of making the push invalid, it just directs it to the user's repo. That also means that a git pull; git push in main will sync main to the fork.

I'll update the docs to reflect this approach.

[jaraco]

I'll update the docs to reflect this approach.

This is done in 3fdba64.

[jaraco]

FYI, Since I last visited this issue, I've implemented jaraco.develop.git.configure_fork, which I use to checkout cpython (and other projects to which I contribute through forks) so that I don't have to remember these steps or refer to any documentation and I get consistent behavior across hundreds of projects.

[CAM-Gerlach]

FYI, merging/rebasing on main will fix the sphinx-lint pinning and detected issues, since it wasn't properly pinned to a specific version before.

[merwok]

A reminder that the merge commit message is pre-filled with all commit messages and should be edited to be brief and useful.