Hi, thank you for your contribution!

Would you think that this feature is best addressed by allowing to simply specify a clone directory as suggested in #653? I feel like that the flag proposed here opts into an overly specific behavior that I'm not looking forward to having to maintain, but that an additional argument could let people wrap this behavior with their scripts if they needed to; for example

ghc() {
  local repo="${1?}"
  gh repo clone "$repo" $repo"
}

ghc owner/repo
cd owner/repo

If so, would you be open to adding that feature instead?

@mislav thanks for taking the time to look over this. I understand the hesitation to commit to overly specific behavior. I wonder if consolidating the clone code into it's own helper might alleviate some of the maintenance burden (since we're calling it in 2 places).

I agree that in the simplest case of gh repo clone foo/bar, an external shell script would suffice. But once we get into more complicated targets, gh has the most context that I don't think we'd be able to replicate in a shell script.

For instance, when using a full URL like gh repo clone https://github.com/cli/cli, the shell script would have to parse the URL to get to cli/cli. And in the case of gh repo fork cli/cli, a shell script wouldn't know that it was actually creating USER/cli.

And if gh starts adding more functionality to determine which repo to clone/fork (like taking into account insteadOf type aliases), that definitely wouldn't be possible in an external script.

I also included a possible fix for #653. It's not the prettiest implementation, but it works. It essentially parses the extra args to find any orphaned ones, Ideally we could somehow leverage git's actual command line arg parsing, maybe through something like this. But this is pretty much my first go code, so I wasn't really sure how to go about doing that.

I'm going to split this PR real quick so that work stands on its own.

I agree that in the simplest case of gh repo clone foo/bar, an external shell script would suffice. But once we get into more complicated targets, gh has the most context that I don't think we'd be able to replicate in a shell script.

That's a good point. Maybe in the future we can contemplate passing a "template" argument to designate the clone target:

gh repo clone -t ~/projects/:owner/:repo cli/cli

Here, the placeholder values would get filled in with resolved owner and repo names.

However, I think it's still premature to discuss such a feature, and I would rather that we focus on a straightforward, static clone destination argument for parity with git clone.

Thank you!