Ask HN: When did GitHub replace standard Git commands with the “GitHub CLI?”

55 points by strix_varius ↗ HN
Today I went to check out a colleague's branch, and noticed the standard `git` one-liner has been replaced with a `gh` one-liner: `gh pr checkout 1234`. Underneath, there's some subtle advertising: "Work fast with our official CLI. _Learn more._"

This is of course useless to me, and to any other developer who prefers to use standard tooling rather than proprietary lock-in stuff.

I don't begrudge Microsoft shipping a GH CLI as an optional thing, but shifting workflows away from the standard client is one of those changes that doesn't serve users, but rather serves some PM's KPIs.

EDIT: based on the "not on my machine" responses here, it's clear that I'm on some branch of an A/B test. These are the only three options now presented in my GH web UI - all the rest have disappeared (https://imgur.com/P7llsVo):

1. Checkout with the GitHub CLI

2. Checkout with GitHub Desktop

3. An ad for buying Codespaces for this public repo

80 comments

[ 2.4 ms ] story [ 139 ms ] thread
Embrace. Extend. Extinguish.
That was a noble business strategy in the late 90s. The only thing Microsoft has managed to extinguish in the last 20 years is an ad-free start menu.
I don’t know about that. A lot of folks seem to have ditched real Linux when Microsoft added Linux in windows. Docker seems to have played a role also.
This sounds like Google tbh. Don't think Microsoft is really notable for this anymore.
Name a single thing that Google has applied this strategy to...
(comment deleted)
Google is more along the lines of: Invent. Deprecate.
I just tried it now. The default is still HTTPS when signed out and SSH when signed in. The `gh` workflow seems to be the default only for those who have authenticated using the tool.
I don't have the tool installed, so I suspect it's more likely that we're on different branches of an A/B test.
Nothing that can't be fixed with a browser addon, or using a local client or terminal commands to figure out what to put into a `git checkout`.
It's tiring how reactionary the average HN commentor/contributor can be. It's not a replacement for standard git commands, it's a set of tools for interacting with GitHub. There are other commands for interacting with repos in GitHub specific ways so leaving out cloning a GitHub repo would have felt like a strange omission. Of course they're going to promote their own tool on their own website, that is generally how businesses work. You don't have to use it, no one is making you use it.
(comment deleted)
while a PR doesn't exist in git it is no more than a branch with extra data attached to it

I've been using GH at work and personally for a while now and i never wanted/needed to use the GH CLI/GUI, the IDE will cover you if you need it to.

If they really removed the easy to use copy button it would be annoying but calling it "extinguish" is definetly some HN warrior attitude. They didn't remove it though, just moved it a bit and OP is being a bit dramatic

> It's tiring how reactionary the average HN commentor/contributor can be.

On the contrary, HN is great because most users stick to the subject of discussions rather than devolving into ad-hominem attacks.

It's curious that your account was created exactly one minute after this post was posted, for precisely one insulting comment.

They're right though. HN users are generally only viewed favorably by other HN users, it's a community that is dominated by reactionary pedants. I say this realizing that I too am a reactionary pedant.
I finally made an HN account just for this comment. Feel free to look up the username, it's not a throwaway.
You "finally" made an account to be counter-reactionary for MS? This improves the conversation how?

- - - -

MS has a long long history, any animosity they receive is well-earned. E.g.:

> "Embrace, extend, and extinguish" (EEE),[1] also known as "embrace, extend, and exterminate",[2] is a phrase that the U.S. Department of Justice found[3] that was used internally by Microsoft[4] to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

> The strategy and phrase "embrace and extend" were first described outside Microsoft in a 1996 article in The New York Times titled "Tomorrow, the World Wide Web! Microsoft, the PC King, Wants to Reign Over the Internet",[5]

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

"Ask HN: GitHub just added a feature I don't like to GitHub" is a conversation worth having?
I think the conversation of "Microsoft is currently in the Extend portion of Embrace, Extend, Extinguish, what are your thoughts?" is worth having.
> 1996

It's now 2023; 27 years later.

Name a single thing Microsoft has EEE'd in the last 20 years. There isn't one. All the examples from the Wikipedia page are from the 90s or early 2000s at best (and most of those seem to be about lawsuits for things that happened a few years earlier). The only recent mention is about "Windows Subsystem for Linux", and those fears turned out to be entirely unwarranted.

Do I like Microsoft? Not especially; it's a large corporation that acts in its own self-interest in an a-moral way. But it's also no longer the Microsoft of the 90s. In fact, almost everything is different: leadership, employees, revenue stream, business model.

I recently bought a couple of cheap "college kid" laptops from the mall to use as dumb terminals. Before installing Linux on them I figured I'd play a round of my favorite old video game "Rome: Total War" (i got a Steam account just for that. Oddly the game won't play on Linux (although I'm sure I recall playing it through Wine back in the day, but maybe that's wrong?) so I figured I'd keep Windows on one of the laptops long enough to play through a round of the game.)

The laptop would not let me start to use it until I had activated Wi-Fi and connected a Microsoft account! It literally would not leave the init wizard until I had "phoned home" to the corporate cloud.

> Name a single thing Microsoft has EEE'd in the last 20 years.

See above.

- - - -

In reply to nfinished sib comment:

> "Ask HN: GitHub just added a feature I don't like to GitHub" is a conversation worth having?

So why are you?

The whole Windows activation story sucks; 100% agree on that. But it's not "EEE". I don't follow how it's even remotely similar.

Aside: I just have a Windows VM for testing, but I bypassed the account "requirement" for that by disconnecting from the internet when installing Windows.

> I don't follow how it's even remotely similar.

Well then I don't know what to tell you. From my POV as a "Free" software fanatic* it all seems "of a piece": VS Code is a Trojan Horse, GitHub is insidious, etc.

(* I'm one of those who sees the "Open Source" movement as a distraction from the main point of the "Free" software movement, although I have to admit that most people haven't heard of either of them, and of those who have, most can't or don't distinguish them.)

Embrace, extend, and extinguish is a very specific term, which means – quoting Wikipedia – "a strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors."

I just don't see how "need Microsoft account to log in to Windows" even remotely fits that. I don't know of anything Microsoft has done in the last 20 or so years that fits that. I can tell you of specific things Microsoft has done in the last 20 years that I don't like, but that doesn't make it embrace, extend, and extinguish.

I think especially if you want to promote Free Software it's very important to keep a cool head and not get too clouded by past grievances. IMHO people are fighting yesterday's war with all of this to the detriment of today's war.

> Embrace, extend, and extinguish is a very specific term, which means – quoting Wikipedia – "a strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors."

That sure sounds like gh vs git to me (the thing this thread is about.)

> I just don't see how "need Microsoft account to log in to Windows" even remotely fits that.

The have embraced and extinguished the very idea of owning your own computer. These laptops come configured as dumb terminals for their corporate cloud. They EEE'd the Dynabook yo!?

> I don't know of anything Microsoft has done in the last 20 or so years that fits that.

I'm sure there are examples of MS following their playbook over the last three decades, I'm not going to "google it for you", there are probably lists kept by people who care more than I do.

> I can tell you of specific things Microsoft has done in the last 20 years that I don't like, but that doesn't make it embrace, extend, and extinguish.

I feel like you're missing the forest for the trees. The EEE thing is a strategy or tactic to achieve the overall goal: getting between people and their hardware and "extracting rent". That's their whole thing, yeah?

GitHub acquisition, VS Code, etc. Everything they do is EEE, whether it looks like a sheep or a wolf, it's a wolf.

Incidentally, that's why I don't accept the "Ship of Theseus" idea that MS has turned over in the last few decades. The ship is still a ship.

> I think especially if you want to promote Free Software it's very important to keep a cool head and not get too clouded by past grievances.

That's what I'm saying: the very idea that these grievances are past is exactly what I have a problem with, because they're not past. If anything, MS is succeeding.

> IMHO people are fighting yesterday's war with all of this to the detriment of today's war.

Following the war metaphor, I think we (the Free software folks) have clearly lost completely. We have been roundly defeated. Most people have never heard of us, let alone know what we're even about.

The closest thing to a front in the "War of General Purpose Computing" is the farmers fighting the tractor companies for the right to repair their tractors now that they have computers in them.

In any event, well met. Cheers! :)

> HN is great because most users stick to the subject of discussions rather than devolving into ad-hominem attacks.

On at least three topics I've consistently found this to not be the case: Google, Microsoft, Cryptocurrency (also: Richard Stallman, suckless, but those come up less often).

I find that these threads often devolve pretty fast away from "the subject". I actually dislike all three of those things as well; I use none of their products save for GitHub and haven't for years. But that doesn't mean that everything these companies do is part of a sinister machiavellian plot to take over the world. And not everyone involved in crypto is a sociopathic scammer looking to steal your money, either, even though I think crypto overall is a net negative.

> It's curious that your account was created exactly one minute after this post was posted, for precisely one insulting comment.

I'm really not trying to "gotcha" here, but you're kind of proving my point with this remark.

This post reads as unnecessary FUD. You aren’t forced to use the CLI. If you choose to use it, some workflows are simpler.

The only part of the commit response I care about is the URL to create/view a pull request. It’s pretty easy to ignore the rest.

For the very reason that you're still looking up how to checkout a pull request, git's CLI is not super intuitive and the gh tools appears to be trying to simplify it for their customers. Also realize that the entire concept of a pull request is foreign to git (it is a GitHub invention, Linus never designed git for pull request style development), so they likely want to add tooling to make it easier to use.
Checking out the branch via git is a single command that's neither longer nor more complicated than the "gh cli" version.

For years, it's been the default command in a single-click "copy" field under the "code" dropdown in a PR, not because git is complicated and anyone needs to "look up" the command, but because that's a fast and efficient way to grab a branch.

Replacing the `git` single-liner with a `gh` single-liner does nothing for the user but make them dependent on the `gh` tool.

Counterpoint: git is complicated, it's commands are IMHO inconsistent, and users very frequently need to look up how to do relatively common tasks.
Having to use per-vendor tools for git seems more complicated than using single tool for all Git services.

I don't mind gh as an additional tool but OP's description suggests that Microsoft tries to replace git with gh entirely.

What git command tells you the fork on github.com that wants to send you a pull request?

(Hint: there is none, only the gh tool and GitHub api know it)

That's because "the fork on github.com sending a PR" is very specifically a feature of GitHub, not git itself.
That's not something you need to know in order to checkout a pull request's branch at all.
Most pull requests are from forks of a repo. What's the single command with git to add the others repository and checkout the branch related to the PR?

gh pr checkout 123

That's just for convienance. It does a few things...

1) looks up the pull request to find the proper repository and branch on it.

2) adds the repository if not already added

3) checks out the branch the PR is based on

How would you do that with just git?

I see gh pr checkout as a convenience. It just makes it less work.

Not a single command, but looking up other repositories is not necessary. Pull requests will create refs in the repository against which the PR was created, which you can then fetch.

    git fetch origin refs/pull/123/head
    git checkout FETCH_HEAD
This is actually somewhat preferable to me, because I don't always want to _checkout_ the PR. For example if I’m looking to integrate it into my branch via the CLI, its a

    git fetch origin refs/pull/123/head
    git merge --ff-only (or whatever) FETCH_HEAD
"gh pr" runs several git commands (5 to be exact):

  % gh pr checkout 132
  RUN: git fetch origin refs/pull/132/head:joris_tests_20230119
  From github.com:BurntSushi/toml-test
   * [new ref]         refs/pull/132/head -> joris_tests_20230119
  RUN: git checkout joris_tests_20230119
  Switched to branch 'joris_tests_20230119'
  RUN: git config branch.joris_tests_20230119.remote origin
  RUN: git config branch.joris_tests_20230119.pushRemote origin
  RUN: git config branch.joris_tests_20230119.merge refs/pull/132/head
It just so happens that my local "gh" build prints this as I was debugging a problem some months ago and I never bothered building it again without this on account of being a lazy git.

The entire reason I have "gh" on my system is to easily check out PRs and to set them up so I can push to them with a minimum of mucking about. I use it for noting else.

I do agree it would be nicer to also add the git commands (plural!), but I suspect they just didn't because it's multiple commands to get the same experience. That is: UI reasons, not anything sinister.

> proprietary "gh cli"

It's not "proprietary": https://github.com/cli/cli/blob/trunk/LICENSE

And as you can see in the output above, it's just a wrapper around some git commands. If you want to call this "proprietary" then you should also call tig, got, and other alternative interfaces to git "proprietary".

> It's not "proprietary"

Fair. It is non-standard, published via Microsoft, and even named after the single product that it supports, but if we're splitting hairs it does technically have an open-source license. So I removed the term "proprietary."

Non-standard is fair. I do think it matters, because certainly in free software/open source context "proprietary" tends to have a pretty specific meaning.

The thing is, almost all of "gh" is an interface for GitHub: you can list issues, close issues, comment on issues, do all sorts of stuff with Actions, releases, your account", etc.

And oh, it can also do some limited stuff with git, kind of as an extra. Looking at the gh help output, the only commands are "gh repo {clone,sync}" and "gh pr {checkout,diff,merge}". I guess the repo clone/sync was added for completeness sake (other repo subcommands all relate to GitHub UI stuff), and gh pr is there because all of that is kind of non-trivial if you also want to be able to push to other people's PRs (not impossible or even difficult, just non-trivial and somewhat non-obvious).

In short, I think people are assuming a lot about all of this and there really isn't that much to see.

Actually the `gh clone` wraps up all the complexity with enterprise authn/authz, Tokens/PATs, multi-org SSO/MFA, etc really well. This alone is the reason I use gh.
Ah right, I never actually used the command.
> "gh pr" runs several git commands (5 to be exact):

Only the first two are actually important though (the rest smell like an antifeature to me in fact). I have them both as a single `git pr <remote> <PR>` alias:

    [alias]
        pr = !sh -c 'git fetch $1 pull/$2/head:pr-$1-$2 && git checkout pr-$1-$2' -
...and an equivalent for GitLab:

    [alias]
        mr = !sh -c 'git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2' -
You could easily hardcode remote to be "origin" and get what `gh` does.
> the rest smell like an antifeature to me in fact

I believe without it you can't push to a PR? As a maintainer, I find it quite useful: if a PR is essentially fine but needs a minor/trivial edit (typo, maybe add a few lines of documentation, extremely minor code style changes) then I typically just make then myself as I don't want to bother the submitter for that. Faster and easier for me, faster and easier for them.

Either way, of course all of this is possible without the "gh" tool – no one claimed it's not, – but it's a lot easier than "stick these commands in your git config", especially for people not well versed in git.

Of course you can. You can always use the long form, or set it up explicitly - I sometimes do that too as a maintainer. Setting this up by default when you just want to checkout means that it's easy for you to push things to other people's repos by accident.
same could be said about google replacing imap/smtp as "Insecure Apps" Many developers jump on the gmail/gh band wagon is because they claim to support open standard. As these company replaces these open standards may be time for people to leave the platform.
> Also realize that the entire concept of a pull request is foreign to git (it is a GitHub invention, Linus never designed git for pull request style development)

Doesn't seem quite true, as `git request-pull` command exists since 2005.

Do you see GitHub using that command? It's designed for email workflows and only spits out a message you can copy into an email to the maintainer. GitHub does not use email workflows.
Your original claim was that

> the entire concept of a pull request is foreign to git

which is incorrect, since the the concept already existed, but was simply

> designed for email workflows

Indeed, GitHub-specific pull-requests didn't exist before GitHub, but that's a tautology, isn't it?

It's not. GitHub's idea of pull request is different than what `git request-pull` does, it just uses the same name, which causes confusion. For example, GitLab uses "merge request" to represent the same idea as GitHub's "pull request".
I'm not ashamed to admit that I just really like the GitHub Desktop app. It's super easy to use, integrates nicely into GitHub.com and Azure / GitHub Enterprise which is what 100% of my clients use. It has every feature I need except:

- an easy way to reset but I just switch to the command line for that - it's the only cli command I have to know

- decent submodule support (at least, as of the last time I was on a project that used these awful things)

- decent cherry picking (which I've only had to use when on project with awful merges - like when using submodules...)

There is no shame in using the tools you like best, whether they be GUI or CLI.

I use the command line for everything but resolving merge conflicts. I really like the JetBrains UX for resolving them!

Nothing to be ashamed of either. Several years ago, there was a GitHub Desktop app that neatly contained git binaries with added GitHub UIs. That's what finally made Git "click" for me. I no longer use it, and tend to use the Git CLI and JetBrains' tooling, but I still enjoy GitHub-CLI to easily checkout PRs.
Just checked to see if I just missed it when i use GH

when cloning a repo you get 3 tabs instead of 2 before which are HTTPS,SSH,GH CLI

based on the gh command you wrote you were trying to checkout a branch related to a PR so i tried that on top there is now the `Checkout with github CLI` section but underneath it there is `Checkout with Git` with the HTTPS or SSH options

yes, they changed the layout and put their CLI on top (which came before microsoft btw, unrelated to them) but there is still the original workflow right there

Either OP is on some A/B bucket where they "deleted" git or OP didn't bother to look

OP is definitely on an A/B bucket, because I get two tabs: Local & Codespaces.

Local has two options: "Checkout with the GitHub CLI" and "Checkout with GitHub Desktop."

Codespaces is an ad for buying codespaces for this repo (none exist).

If you usually use SSH but are logged out, the SSH tab disappears, which might explain why Gitlab CLI is being shown.
This confused me as well. A better user experience would leave the ssh tab, and explain why it may not work for a particular user?
> shifting default workflows away from the standard client is one of those changes that doesn't serve users

There is no "default workflow" for git - Git can be used in a variety of ways; everyone has their own personal preference, and some of these workflows are shaped by interacting with systems like Github/Gerrit/etc.

Every place I've ever worked at has either:

  - a home-grown wrapper around git to make common operations easy
  - a recommended set of git aliases around common operations
The fact that Github has created their own to interact with their own system is a net win for individuals/organizations who would otherwise need to spend time scripting their own.

Of all the capabilities of the Github CLI, `gh pr checkout` is the only one I use, because it makes it easy to fetch a PR locally by ID without configuring a remote per fork. I'm pretty glad I didn't have to write this myself.

> > shifting default workflows away from the standard client is one of those changes that doesn't serve users

> There is no "default workflow" for git

The default workflow, as in what Github promotes. Github's default, not git's. That's what's meant.

As a sub menu from the "<> Code" Button? I have 3 tabs, HTTPS, SSH and this new Github CLI tab, but it remembers the last tab selected and always shows that
I love the gh tool. I still use `git switch` 95% of the time, but when a someone opens a PR on one of my repos being able to `gh pr checkout 123` is way easier than finding their fork, cloning and switching to the relevant branch.

The feature of gh I use most is `gh pr create`. It lets me combine the pushing of my current branch with creating a PR, allowing my to type the description using my text editor and has a nice interface for adding on reviewers etc. There's even a 'continue in a browser' button at the end if you want to add some screenshots.

It's an outstanding tool.

> being able to `gh pr checkout 123` is way easier than finding their fork, cloning and switching to the relevant branch.

Of course it's easier than what you described, but that's not something you ever needed to do in order to checkout a pull request's branch; all you need to do it to checkout `pull/<ID>/head` from the repo PR has been made against - and that's what `gh pr checkout` does too.

(there's also `pull/<ID>/merge`, which contains the PR's branch already merged into target branch)

This works with GitLab too BTW, but you have to replace `pull` with `merge-requests`.

Well, TIL. Thanks for the tip!
It's not a replacement for git. I used the github cli recently to search for all repos in a specific language, above a certain star count, no archives, & no forks; then piped it into other commands to clone, rename, and archive the repos. It's a very convenient way to interact with github features without visiting the site in a browser.
Microsoft 101--embrace, extend, extinguish. We've seen the GitHub embrace step, now we're seeing the extend part, next comes the lock in and closing off of GitHub.
The only odd thing I am seeing is network congestion on their side. It seems the bog standard git tool is working as expected for me. I am not seeing any advertisements for a new tool.
A/B testing is the worst. YouTube tried out the idea of going straight from app-load into their TikTok mode (or whatever it’s called) on me a handful of times. I had a feeling they were collecting as much data as possible so every time I just uninstall the app for 24 hours. “Bad dog, no treat.”
I not sure to understand but GH CLI is a free software (MIT License). If you already use Github, there is no more proprietary software.

https://github.com/cli/cli

It's still vendor lock-in and only works for one code host.

git doesn't care who hosts your code

I do hope the endgame isn't to get rid of git completely and switch tge repos to some proprietary format.
> Today I went to check out a colleague's branch, and noticed the standard `git` one-liner has been replaced with a `gh` one-liner: `gh pr checkout 1234`

Wait, I'm a bit confused. Where you on the "branch" or on the "pull request" UI? If they replaced the instructions to check out an arbitrary branch, I could understand the outrage. But this looks like a command to check out a pull request. To my knowledge, there is no standard git command to do this. (Because "pull requests" are a github/gitlab/etc concept not a git concept as the sibling comments explained)

If they just added instructions for the github client for things you can't do with the normal git CLI, that seems perfectly reasonable to me.

You can pretty easily check out a PR using the regular Git CLI. GitHub adds refs for pull requests that you can fetch.

  git fetch origin pull/ID/head:BRANCH_NAME
From: https://docs.github.com/en/pull-requests/collaborating-with-...

Sure, the whole workflow isn't a "standard Git workflow" but they could easily provide a command that works with the standard Git CLI.

> but they could easily provide a command that works with the standard Git CLI.

And that's what they used to do there.

I'd heard of GitHub Desktop, didn't know about GH CLI. Don't use either, nor the git/GitHub IDE integration other than 'blame' to show commit hashes/dates on lines. Also use IDE to do 3-way diff conflict resolution, but initiate/commit/continue from command-line.

Do all git mutations from command-line using `git`.

One useful tip is that you can go to github.com/<org-repo>/pull/<branch-name> rather than PR# and it will redirect.

I've found Github Desktop highly useful and intuitive. Is there a specific reason people don't use it?