4 ms·

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 comm

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.

eli 4y ago
Counterpoint: git is complicated, it's commands are IMHO inconsistent, and users very frequently need to look up how to do relatively common tasks.
- voytec 4y ago
  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.
  - qbasic_forever 4y ago
    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)
    - b3morales 4y ago
      That's because "the fork on github.com sending a PR" is very specifically a feature of GitHub, not git itself.
    - seba_dos1 4y ago
      That's not something you need to know in order to checkout a pull request's branch at all.
mfer 4y ago
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.
- nagisa 4y ago
  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
arp242 4y ago
"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 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".
- strix_varius 4y ago
  > 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."
  - arp242 4y ago
    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.

eli 4y ago

Counterpoint: git is complicated, it's commands are IMHO inconsistent, and users very frequently need to look up how to do relatively common tasks.

voytec 4y ago
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.
- qbasic_forever 4y ago
  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)
  - b3morales 4y ago
    That's because "the fork on github.com sending a PR" is very specifically a feature of GitHub, not git itself.
  - seba_dos1 4y ago
    That's not something you need to know in order to checkout a pull request's branch at all.

mfer 4y ago

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.

nagisa 4y ago
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

arp242 4y ago

"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 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".

strix_varius 4y ago
> 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."
- arp242 4y ago
  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.