Would be nice to get prompted to run `glab config init` to set `gitlab_uri` if supplying a `--hostname` to `glab auth login`

[espoelstra]

Is your feature request related to a problem? Please describe. When attempting to clone from a host the initial attempts fail immediately because it was assumed gitlab.com and the repository of course doesn't exist there even though I had run the glab auth login --hostname mygitlab.host.

Describe the solution you'd like If glab auth login --hostname is invoked but glab config --global get gitlab_uri isn't set it should warn the user that to use that host for any clone operations (since there is no local repository for glab to examine for a hostname) they need to set the global gitlab_uri before attempting the clone again or by setting/exporting the GITLAB_URI or GITLAB_HOST variables before/when running the glab clone command.

Perhaps the user should be prompted to run glab config init if any glab <action> commands are run and the host: key doesn't exist, the default of using the unconfigured gitlab.com makes sense, but is "implicit" vs "explicit" and might not be obvious to most people and will probably lead to a lot of bugs.

Otherwise maybe glab could prompt the user to select a host during the glab clone where gitlab.com is the default but it automatically shows any other hosts that it has some API credentials to access in the config file.

[profclems]

@espoelstra thanks a lot for detailing your case. This really makes sense. I agree with prompting the user to select a host. I will add it to my backlog and see if I can submit a fix within the week.

It is however open for anyone who would like to submit a fix sooner

[zemzale]

I would imagine we could also default to the available hosts in the config and work from there. If there is only one host setup and it isn't gitlab.com, we default to that. We could also tell user that we used this host because gitlab_uri(or whatever value is used for getting the default host, I don't know how this exactly works) wasn't available.

[profclems]

If glab is run from a git repository, it looks through the git remotes available and checks if any of them is authenticated. It is extremely rare to have multiple authenticated hosts in a single repository but if that happens, glab gives priority to the remotes nicknames in this order upstream > gitlab > origin. If there are multiple remotes pointing to the same hosts, like:

$ git remote -v
origin  git@gitlab.com:zemzale/glab.git (fetch)
origin  git@gitlab.com:zemzale/glab.git (push)
upstream  git@gitlab.com:profclems/glab.git (fetch)
upstream  git@gitlab.com:profclems/glab.git (push)

glab will merge them into a single host since they are both pointing to gitlab.com and ask the user at first run, which of the repos to use and it caches it in the git config:

? Which should be the base repository (used for e.g. querying issues) for this directory?
> profclems/glab
  zemzale/glab

This happens especially with forks

[clemsbot]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[clemsbot]

This issue has been automatically marked as stale because it has not had recent activity. We haven't had the time to address it yet, but we want to keep it open. This message is just a reminder for us to help triage issues.