4 ms·

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 simpl

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.

strix_varius 4y ago
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.
x98asfd 4y ago
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.
bheadmaster 4y ago
> 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.
- qbasic_forever 4y ago
  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.
  - sieabahlpark 4y ago
    [dead]
  - bheadmaster 4y ago
    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?
    - seba_dos1 4y ago
      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".
TrueGeek 4y ago
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...)
- clintonb 4y ago
  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!
- Ayesh 4y ago
  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.

strix_varius 4y ago

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.

x98asfd 4y ago

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.

bheadmaster 4y ago

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

qbasic_forever 4y ago
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.
- sieabahlpark 4y ago
  [dead]
- bheadmaster 4y ago
  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?
  - seba_dos1 4y ago
    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".

TrueGeek 4y ago

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

clintonb 4y ago
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!
Ayesh 4y ago
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.