Fallback clone from user organization

[maaslalani]

Fixes #2000

This PR solves a problem I generally encounter when cloning repositories. This
is a pretty specific and personal annoyance so feel free to close if it doesn't
fit into the philosophy.

When cloning repositories, I sometimes forget to add the owner:

$ gh repo clone lipgloss

Then, I receive an error:

GraphQL: Could not resolve to a Repository with the name 'maaslalani/lipgloss'. (repository)

Then, I specify the owner and everything is fine:

$ gh repo clone charmbracelet/lipgloss
# Cloning into 'lipgloss...'

It would be quite nice if gh could clone the repo for me if it knows which
organizations I generally clone from (the ones I belong to). This PR performs a
fallback to cloning the repository if the user doesn't specify the owner.

So, if a user runs:

$ gh repo clone lipgloss

The clone will first try maaslalani/lipgloss, find that it is not there,
then either tries NixOS/lipgloss or charmbracelet/lipgloss and clones
charmbracelet/lipgloss since it exists.

NB: If the user runs:

$ gh repo clone maaslalani/lipgloss
# GraphQL: Could not resolve to a Repository with the name 'maaslalani/lipgloss'. (repository)

They will receive the same error since they explicitly mentioned the
organization they wanted the repository from.

---

Some improvements to add (if we want to continue with this approach):

1. Inform the user which repository we're cloning from if it's a fallback.
2. Add tests:
   2.1. gh repo clone dotfiles, repo does exist in user.
   2.2. gh repo clone lipgloss, repo does exist in fallback org.
   2.3. gh repo clone obviously-doesnt-exist-anywhere, repo does not exist anywhere.
   2.4. gh repo clone maaslalani/lipgloss, repo does not exist in explicit owner, but does exist in org.
   2.5. gh repo clone charmbracelet/lipgloss, repo exists in org.
   2.6. gh repo clone .github, repo exists in multiple orgs.
3. Make org limit configurable, current set to 5.

[andyfeller]

This PR solves a problem I generally encounter when cloning repositories. This
is a pretty specific and personal annoyance so feel free to close if it doesn't
fit into the philosophy.

I can tell you I have clones from multiple organizations and this has bitten me numerous times, too. ❤️

[andyfeller]

I've long wished we had a way to capture an owner for a given directory for those of us who organize based on organization:

cat ~/.config/gh/config.yml
aliases: {}
version: "1"
directoryOwners:
  path/to/owner: owner
  path/to/owner2: owner2

[williammartin]

If we do proceed with something like this we need to ensure this only happens if opts.IO.CanPrompt() is true. This supports people who aren't using TTY and anyone who has GH_PROMPT_DISABLED set.

[maaslalani]

Ah, nice, that makes sense. Thanks for letting me know. If we do proceed with this do we want to show an accessible menu that huh provides (in the event of people using screen readers)? Perhaps introduce GH_PROMPT_ACCESSIBLE? This could also come later as well.

[williammartin]

Initially playing around with this I'm not sure about the current approach. The primary concern is that listing the orgs can easily be more confusing or annoying than not. Here's what I experienced:

There are two problems here:

• None of these orgs actually contain cli
• The org that does contain cli isn't included

I don't think expanding the list of orgs by itself resolves this. It would be nice if we could search within the orgs that the user is a part of and only show those but unless GitHub search supports this (have asked to see if anyone has any ideas) that would involve a lot of network requests as you saw in 9bf322b.

[williammartin]

Maybe there are some heuristics we could apply like:

• If the org list only contains n orgs, query them to see whether they contain a repo of the correct name, and only show those
• If the org list contains more than n orgs, show the whole list

Would that solve for the most common case, while keeping the request count down?

[williammartin]

@maaslalani how often do you want to clone from charmbracelet and maaslalani without providing the owner/? In #2000 the team said they would accept default_owner but that's a bit different than fallback which is the word you used.

[maaslalani]

Maybe there are some heuristics we could apply like:

• If the org list only contains n orgs, query them to see whether they contain a repo of the correct name, and only show those
• If the org list contains more than n orgs, show the whole list

Would that solve for the most common case, while keeping the request count down?

Yeah I quite like this approach. I would also add one more case, if the org list only contains n repos and we query them and only one of the queried orgs has the repo, simply clone that one without showing any prompt (If we really want to confirm then would perhaps show a Confirm (yes / no) prompt instead).

---

I don't think expanding the list of orgs by itself resolves this. It would be nice if we could search within the orgs that the user is a part of and only show those but unless GitHub search supports this (have asked to see if anyone has any ideas) that would involve a lot of network requests as you saw in 9bf322b.

Yeah, you're absolutely correct. I like the idea of having a query that can find repositories matching the name of the repo the user tried to clone with different owners so that all the listed options are valid clone-able repositories. So perhaps, we can list repositories from GitHub matching the name and filter by owners that the user has access to. Is there a query for this?

---

@maaslalani how often do you want to clone from charmbracelet and maaslalani without providing the owner/? In #2000 the team said they would accept default_owner but that's a bit different than fallback which is the word you used.

I almost never specify the owner/ the first time, only when I get an error. This might be sort of an edge case because charmbracelet is a long name. I almost always want to clone from either maaslalani/ or charmbracelet/ so for me I think being able to specify fallback_owner would be better than default_owner since if charmbracelet was the default_owner I would have the same problem but with my cloning my own repos rather than the organizations.

[andyfeller]

Would that solve for the most common case, while keeping the request count down?

What is the most common use case?

1. users with repositories in username space?
2. users only in 1 GitHub organization?
3. users in 2+ GitHub organizations?
4. users who clone OSS repositories?

My experience is that people fall into multiple buckets, very rarely just 1.

Allowing users to change the default owner might be the best now solution

Again, I think the robust solution is enabling users to define the user for a given directory, however that is more work. If we don't want to implement it just yet, it would be easier to iterate on allowing users to change the default owner rather than getting clever on how to find the owner they didn't specify.