I think this is a nice direction but would rather @mislav and @ampinsk weigh in.

As I mentioned in issue #847, I didn't learn Go yet! The offline fork I had is mostly based on the previous implementations.
So I don't know how to fix the tests! If someone can give guidance on how to fix, I will try to fix them!

I came here looking for an issue to add an optional name to the fork itself, not only the remote name – for example, when several repos have the same name, but within different user or org workspaces. Don't want to derail this PR, just checking to see if there's some common use cases here. A few other things that feel related:

• recent changes: Improve repository base and head resolution #1706
• similar need, different workflow: rename repository command #1399

i'll see this through. TODO:

• add option for accepting remote name
• in case of conflict, error and tell to use remote name flag
• tests

new behavior:

Thanks @vilmibm for your work! 😄

So this is changing the previous behavior, right? If you cloned a repo from origin, then added a fork, you would have the old origin be added to the upstream remote, and the new origin would be your fork. As I understand, this isn't possible anymore:

https://asciinema.org/a/DRebWnUq73hVcNAY8lZdVXolV

As much as I like having the option to pass a name, this is marked as an addition, but it's also a feature removal, and it'll be missed :c

Is a compromise here a --rename flag that restores and opts into the old behavior?

Good enough for me :)

In my opinion a flag would not resolve it.
if i simply run gh repo fork I would prefer it assumed if something is named origin it should rename it to upstream as in the previous behavior.
now if you run gh repo fork --remote-name than no renaming needs to happen so why add the rename flag?

Perhaps rename flag could be added if the remote found was unexpected as in not origin
Maybe I am different as I preferred the magic instead of being prompted and I also prefer not to have to remember each incantation of flags.

If anything though gh repo fork still lacks the ability to rename the repo before forking it which is a bigger issue than what your remote is called locally but I digress.
Fine --rename would work, I'll just end up wrapping the command 😅