Thanks for reporting! Try this workaround:

gh repo fork --remote

Explanation: most gh commands do operations on the current repository and, alternatively, they take the repository via argument or flag. You've passed a repository argument by doing $(git remote get-url up). In that case, this signals to gh that you want to ignore the current local git repository that you're in, and therefore gh avoids touching the local git repository, including setting any new git remotes.

I think the "fix" here would be to have --remote flag error out if it's used in combination with the repository argument.

How does gh work out which remote to fork if you don't provide it as an argument? Does it just pick one at random?

I want to both specify the remote to fork, and also have it add a new fork remote. I'm happy to script around gh, but as it doesn't return the URL of the fork I don't think I can.

How does gh work out which remote to fork if you don't provide it as an argument? Does it just pick one at random?

No. For each local repo that has multiple GitHub remotes, gh tries to resolve the "base" remote by:

1. If an interactive terminal is detected, the user is asked to select one. The choice is saved per-repository.
2. If no interactive terminal, then the first remote is taken in this order: upstream, github, origin. If none of those remotes are found, the first remote (in alphabetical order) is taken as a "base" remote.

I want to both specify the remote to fork, and also have it add a new fork remote.

Sorry, specifying the remote to fork isn't available right now. Could you describe your use-case with several remotes?

In the meantime, you could use the api command to manually fork any repo and get its URL:

GH_HOST=my.enterprise.host gh api -XPOST repos/OWNER/REPO/forks | jq '.clone_url'

Sorry, specifying the remote to fork isn't available right now. Could you describe your use-case with several remotes?

Current remotes:

• ghe -> GHE internal mirror
• pub -> github.com public repo

Desired Remotes:

• ghe -> GHE internal mirror
• ghefork -> my GHE internal mirror's fork
• pub -> github.com public repo
• pubfork -> my github.com fork

I want to be able to fork repos and then clean them, so they don't have duplicate branches, this requires pushing the head ref of the "up" remote to its "fork" remote.

Current alias: https://github.com/gibfahn/dot/blob/7f16e16f1d34046e80f48fb3ce86415ddc1779c3/dotfiles/.config/git/config#L7 , it uses hub, which also doesn't have a way to specify this.

@gibfahn Thanks for describing your use case! We need to ponder about this. Right now we don't have good support for mixed GHE GitHub.com remotes.

It looks like you would need a way to select a remote to fork and also to choose how the new remote for the fork should be named. E.g.

$ gh repo fork --remote=ghe --remote-name=ghefork

We need to discuss with the team whether this is something that we would want to enable.

@mislav Hasn't this issue been resolved with #1882?

No, but I can see how this is confusing. Thanks for linking that.

The --remote-name flag we added in the meantime isn't for selecting the remote to be forked: it's for selecting the name of the new git remote to be added after forking.

This thread describes a bug and a feature, none of which were yet addressed:

• bug: specifying gh repo fork <repo> --remote=true ignores the --remote flag because the repository was explicitly passed
• feature: there should be a way to select the base remote that a gh operation should apply to (in this case, specify the remote of the git repository to be forked)

Is there any chance of skipping any interactive shell when you interact with another?

Hi @mislav , I've been taking a look at this and tried to make a simple fix for the first item in your list . I used the comment below as a guide.

I think the "fix" here would be to have --remote flag error out if it's used in combination with the repository argument.

Regarding the second item, I saw the comment below which I believe it references it. I would like to know if a conclusion has been reached regarding this? I would be willing to have a go at this part as well (if the conclusion is to go ahead), would maybe need some pointers though.

We need to discuss with the team whether this is something that we would want to enable.

I can also open a PR with only the first part if you prefer.