Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"gh" git alias clashes with github-cli #1498

Closed
jmthvt opened this issue Feb 20, 2020 · 6 comments · Fixed by #1499
Closed

"gh" git alias clashes with github-cli #1498

jmthvt opened this issue Feb 20, 2020 · 6 comments · Fixed by #1499

Comments

@jmthvt
Copy link
Contributor

jmthvt commented Feb 20, 2020

GitHub released a new CLI https://cli.github.com/
The command is called gh, which clashes with the gh alias set by the bash-it git plugin.

@nwinkler
Copy link
Member

Not sure what we want to do about that... We've had conflicts before (see #825, #867, and #141), similar discussions there. We will not be able to make everyone happy.

If you are using both the Bash-it Git aliases and the GitHub CLI, you can still include a unalias gh in a custom Bash-it script or in your Bash init script after Bash-it has been loaded.

Ironically, there has been a similar discussion on GitHub's CLI a while back, from what I remember, back then they switched from a previous version of gh to hub. They seem to be moving between these two every couple of years. Not sure we want to be part of that dance... See #392 for more details.

@jmthvt
Copy link
Contributor Author

jmthvt commented Feb 20, 2020

Hmm yes I agree we can't make everyone happy, and unset is a solution for anyone wanting to fix it.
However I was proposing to change the alias here #1499 since it's "breaking" the gh command when you install the CLI and it took me some minutes to realise it was just due to this alias. Just want to avoid other people running into this :)

@davidpfarrell
Copy link
Contributor

davidpfarrell commented Feb 20, 2020

Greetings,

I've seen the related PR but thought to discuss here instead of there ...

Would it be useful to :

  • Add the ghome alias (or maybe ghm)
  • Leave the gh alias, but only enable it if the gh command is not found in the path? i think bash-it has a quick check for that?

I think a rule to conditionally-enable aliases is okay when the the alias and the potentially-overridden command are related.

We could think of ghome as the primary alias for its function, and gh as a bonus alias.

Additionally, its feels like a fair assumption that anyone taking the time to install the new gh tool likely wants to access it under that name, and would prefer it over the gh alias.

[edit] Elaboration

@jmthvt
Copy link
Contributor Author

jmthvt commented Feb 21, 2020

@davidpfarrell Sounds good to me, I'll amend the PR.

@nwinkler
Copy link
Member

Yes, that sounds like a good compromise to me as well. I'll take a look at the PR...

@jmthvt
Copy link
Contributor Author

jmthvt commented Apr 9, 2020

PR has just been updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants