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.
% 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
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".
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."
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.
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' -
[alias]
mr = !sh -c 'git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2' -
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.
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.
git fetch origin refs/pull/123/head
git checkout FETCH_HEAD
git fetch origin refs/pull/123/head
git merge --ff-only (or whatever) FETCH_HEADI don't mind gh as an additional tool but OP's description suggests that Microsoft tries to replace git with gh entirely.
(Hint: there is none, only the gh tool and GitHub api know it)
Doesn't seem quite true, as `git request-pull` command exists since 2005.
> 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?
- 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...)
I use the command line for everything but resolving merge conflicts. I really like the JetBrains UX for resolving them!