cli / cli

GitHub’s official command line tool

GitHub CLI

gh is GitHub on the command line. It brings pull requests, issues, and other GitHub concepts to the terminal next to where you are already working with git and your code.

GitHub CLI is supported for users on GitHub.com and GitHub Enterprise Server 2.20+ with support for macOS, Windows, and Linux.

Documentation

For installation options see below, for usage instructions see the manual.

Contributing

If anything feels off, or if you feel that some functionality is missing, please check out the contributing page. There you will find instructions for sharing your feedback, building the tool locally, and submitting pull requests to the project.

If you are a hubber and are interested in shipping new commands for the CLI, check out our doc on internal contributions.

Installation

macOS

gh is available via Homebrew, MacPorts, Conda, Spack, Webi, and as a downloadable binary from the releases page.

Homebrew

Install:	Upgrade:
brew install gh	brew upgrade gh

MacPorts

Install:	Upgrade:
sudo port install gh	sudo port selfupdate && sudo port upgrade gh

Conda

Install:	Upgrade:
conda install gh --channel conda-forge	conda update gh --channel conda-forge

Additional Conda installation options available on the gh-feedstock page.

Spack

Install:	Upgrade:
spack install gh	spack uninstall gh && spack install gh

Webi

Install:	Upgrade:
curl -sS https://webi.sh/gh | sh	webi gh@stable

For more information about the Webi installer see its homepage.

Linux & BSD

gh is available via:

• our Debian and RPM repositories;
• community-maintained repositories in various Linux distros;
• OS-agnostic package managers such as Homebrew, Conda, Spack, Webi; and
• our releases page as precompiled binaries.

For more information, see Linux & BSD installation.

Windows

gh is available via WinGet, scoop, Chocolatey, Conda, Webi, and as downloadable MSI.

WinGet

Install:	Upgrade:
winget install --id GitHub.cli	winget upgrade --id GitHub.cli

Note
The Windows installer modifies your PATH. When using Windows Terminal, you will need to open a new window for the changes to take effect. (Simply opening a new tab will not be sufficient.)

scoop

Install:	Upgrade:
scoop install gh	scoop update gh

Chocolatey

Install:	Upgrade:
choco install gh	choco upgrade gh

Signed MSI

MSI installers are available for download on the releases page.

Codespaces

To add GitHub CLI to your codespace, add the following to your devcontainer file:

"features": {
  "ghcr.io/devcontainers/features/github-cli:1": {}
}

GitHub Actions

GitHub CLI comes pre-installed in all GitHub-Hosted Runners.

Other platforms

Download packaged binaries from the releases page.

Build from source

See here on how to build GitHub CLI from source.

Comparison with hub

For many years, hub was the unofficial GitHub CLI tool. gh is a new project that helps us explore what an official GitHub CLI tool can look like with a fundamentally different design. While both tools bring GitHub to the terminal, hub behaves as a proxy to git, and gh is a standalone tool. Check out our more detailed explanation to learn more.

cli's Issues

Docs/man-page

I'm working on our man pages that will tie into site design's work on our landing page

• responsive
• sync up with site design
• merge the design to the proper site design page

How do we deal with sections of `pr status` and `issue status` that go beyond 10 rows?

Show a And 4 more (in gray) at the bottom of a list that goes beyond 10 rows

For example (in Created by you):

~/github/test$ gh pr status
Current branch
  There is no pull request associated with [different-stuff]

Created by you
  #11  Add release instructions to readme [blahblah] - review required
  #10  Extract generic row printer that adjusts itself... [new-branch] - review required
  #9  Update syntax highlighting [newnewnew] - review required
  #5  Update readme [conflicts] - review required
  #15  Add release instructions to readme [blahblah] - review required
  #10  Extract generic row printer that adjusts itself... [new-branch] - review required
  #9  Update syntax highlighting [newnewnew] - review required
  #5  Update readme [conflicts] - review required
  #12  Add release instructions to readme [blahblah] - review required
  #14  Extract generic row printer that adjusts itself... [new-branch] - review required
  And 4 more

Requesting a code review from you
  #4  Upgrade dependencies [request-me]
  #2  Update docs [test]

README.md should include instructions on how to build the tool from sources

Describe the feature or problem you’d like to solve

The README.md should give instructions to the user about building the tool from the repo's sources. As of now, it simply instructs the user to use Homebrew to install it.

Proposed solution

Provide instructions on how to compile the tool from sources while keeping the Homebrew section intact.

Additional context

For scope, I am a Linux user, and don't use Homebrew. However, there is a perfectly good set of sources to build from with no instructions on how to do so. With these instructions, I could then create a package for Linux for a managed install on my machine.

No empty state for `pr list`

When there are no PRs in a repo, it should output a similar empty state to issue list

Take templates into account for `pr create` and `issue create`

For gh pr create as far as I can tell, there aren't multiple templates to choose from so this will require just making sure the template is in the editor when you enter the description

For gh issue create, here's how I thought we could let you choose a template:

~/Projects/my-project$ gh issue create

Creating an issue in desktop/desktop

? Choose a template
> Bug report
  Feature request
  No template
? Title This is an issue title
? Body (nano) [Enter to launch editor]

_template in nano_

? Submit? 
> yes
  edit
  cancel

https://github.com/desktop/desktop/issues/4

`Did you mean?` error responses

We want this product to feel like a helpful guide and not make you think too much. To that end, we'd like to implement a "Did you mean [command]?" in the event of misspellings.

The initial version of this should not be interactive but the person will need to retype the command.

Consistent list formatting

gh pr list and gh issue list deal with formatting slightly differently, specifically color and spacing. gh issue list should match what gh pr list is doing:

Update flags language

What currently exists

Global flags:

-B, --current-branch string   current git branch
-h, --help                    help for gh
-R, --repo string             current GitHub repository

Flags for pr create

  -T, --base string    The branch into which you want your code merged
  -b, --body string    Supply a body. Will prompt for one otherwise.
  -d, --draft          Mark PR as a draft
  -h, --help           help for create
  -t, --title string   Supply a title. Will prompt for one otherwise.

Flags for issue create

  -h, --help                  help for create
  -m, --message stringArray   set title and body
  -w, --web                   open the web browser to create an issue

Flags for pr list

  -b, --base string         filter by base branch
  -h, --help                help for list
  -l, --label stringArray   filter by label
  -L, --limit int           maximum number of items to fetch (default 30)
  -s, --state string        filter by state (default "open")

Flags for issue list

  -a, --assignee string   filter by assignee
  -h, --help              help for list
  -l, --label strings     filter by label
  -L, --limit int         maximum number of issues to fetch (default 30)
  -s, --state string      filter by state (open|closed|all)

Proposed new flags

Global flags:

-h, --help                    Help for gh
-R, --repo string             Select GitHub repository
-V, --version .               Version for gh

Flags for pr create and issue create

-B, --base string	The branch into which you want your code merged
-b, --body string	Supply a body. Will prompt for one otherwise.
-d, --draft		Mark PR as a draft
-h, --help		Help for create
-t, --title string	Supply a title. Will prompt for one otherwise.
-w, --web		Create in web browser

Flags for pr list and issue list

-a, --assignee string		Filter by assignee
-B, --base string		Filter by base branch
-h, --help			Help for list
-l, --label strings		Filter by label
-L, --limit int			Maximum number of items to fetch (default 30)
-s, --state string		Filter by state (open|closed|all, default "open")

note: issue create and issue list won't include the --base flag

Flags for pr view and issue view

-t, --text		Output title and body of [issue/pull request]

note: this is new functionality that we can open up a separate issue for

Tasks week of 10/28 👻

Hi @github/ce-cli, This is a more granular task list than what is listed in Neha's demo planning doc.

If you want to share what you are working on put it on the list and put your name next to it. If you are looking for what to do next, find something that isn't claimed and is on this list!

• [master] Finish work on writing and testing gh pr create @vilmibm
• [master] Finish work on refactoring and testing the context package @mislav
• [master] Figure out how the best way to install the gh binary on people's machines
• [master] Handle authenticating git calls
• [master] Add gh issue commands
  • Status
  • View
• [master] Present helpful errors to users (instead of the cryptic errors we see now)
• [prototype] gh pr status with requested changes / approved / requested review #45
• [prototype] gh pr list #42
• [prototype] gh issue create #44

Replace `--version` with `gh version`?

Some commands (ie go) use a version subcommand to return the version. should we do that? it leaves -v available if we ever want a global verbosity flag.

Tasks week of 10/14

Hi @github/ce-cli, This is a more granular task list than what is listed in Neha's demo planning doc.

If you want to share what you are working on put it on the list and put your name next to it. If you are looking for what to do next, find something that isn't claimed and is on this list!

• [prototype] gh pr create (fleshing out with args and better edge case handling) @vilmibm
• [prototype] gh status @vilmibm
• [prototype] oauth flow @mislav
• [master] context package feedback @vilmibm
• [master] Incorporate the stable parts of last weeks demo.
  • [master] gh pr show
  • [master] gh pr help
  • [master] gh pr checkout id|branch @probablycorey
  • [master] Style command output (colorize) #22 @probablycorey
• [master] Continue with Nate’s context work #17
  • [master] Make it work with our existing gh pr commands
  • [master] Ensure that we can mock the context for testing
• [master] Present helpful errors to users (instead of the cryptic errors we see now)

GitHub CLI works on Linux

I should be able to download and use GitHub CLI on my Linux machine.

---

Initially, I (vilmibm) wanted us to be able to work with apt-add-repository via a PPA. I think that's too much given our current timeframe and need to also get Windows figured out, so I'm scaling back to:

• generate .deb files via go-releaser
• generate .rpm files via go-releaser
• add README documentation about installing via .deb on debian/ubuntu
• add README documentation about installing via .rpm on fedora/centos
• add README documentation for installing the binary manually
• add README documentation for uninstalling on linux

Improve experience when no matches found for `pr/issue list --label`

@tierninho #66 (comment):

For gh pr list -l erwerwe - if label is made up, then there is no acknowledgement. I would expects a return of "Label does not match" or "0 found with that label".

We can improve this in several tiers. I will describe my ideas for them using the Expanding Brain meme:

• small brain: no acknowledgement
• normal brain: ”No pull requests found with label 'erwerwe'”
• expanding brain: “No pull requests found: the label 'erwerwe' does not exist”
• galaxy brain: “No pull requests found; did you mean 'swerwe'?” ('swerwe' being an existing label)

Iterate on current `pr create` and `issue create` flows

After a group brainstorm, we settled on these improvements for now:

1. Make the description step skippable

~/github/test$ gh pr create
? Title This is a test title
? Body (nano) [E to launch editor, Enter to skip] 

I'm not sure what the trigger to launch the editor should be, seems pretty arbitrary but open to thoughts!

2. Replace Edit option at the end with Preview in browser

~/github/test$ gh pr create
? Title This is a test title
? Body (nano) <Received>
? Submit?  [Use arrows to move, type to filter]
> Yes
  Preview in browser
  Cancel

This will pop open the browser to a prefilled pull request with the title and body you submitted.

CLI changelog

Describe the feature or problem you’d like to solve

Is there a need to display a changelog for CLI, potentially via the command line?

Proposed solution

Something like gh --changelog or similar so users can learn more about updates. It is helpful for me in case I need to go back and see when a feature was released or if I missed the marketing material.

Feedback issue for bugs & inconsistencies with GitHub CLI

This is an issue to collect feedback about things that may not be working correctly or as expected with GitHub CLI. It's not a place for feature requests, as we'd like our primary product feedback to be from users outside of GitHub. Additionally, this repository will likely become public so please don't share any internally confidential information about upcoming GitHub things in here. Thanks!

To download GitHub CLI for macOS, run brew install github/gh/gh in your Terminal.

Add better messaging to address archived repos

When attempting to interact with an archived repo, we are serving up generic messaging and not alerting the user that the repo is archived.

For example:

➜  prlist git:(aaa) gh pr create -t my-title -b fasfsfsfsdfsdfsdfsdfsd
was not able to push to remote 'origin': exit status 128

should be edit to something more user-friendly like: The repository you are trying to access is archived.

Ensure we're using selectors consistently

We decided that we'd like to allow people to select objects when necessary using (depending on the object):

• PR/Issue number
• github URL
• branch name

I think this just affects gh issue view gh pr view and gh pr checkout for now

Allow skipping of title field in pr create

When creating a new PR or Issue, the user should be forced to enter at minimum a Title before proceeding else they run into this:

➜  prlist git:(tierninho-patch-1) gh pr create
? Title
? Body (nano) <Received>
? Submit? Yes
failed to create PR: graphql error: 'Title can't be blank'

and

➜  prlist git:(tierninho-patch-1) gh issue create
? Title
? Body (nano) <Received>
? Submit? Yes
graphql error: 'Title can't be blank'

gh version 0.3.4 (2019-12-05T13:03:14Z), OSX

Warn on nonexistent issues in `issue/pr view <number>`

@tierninho #66 (comment):

For gh pr view ## and gh issue view ## - [...] if the number is a 404, don't open in the browser or warn user.

I agree that we should look up whether the record exists and avoid opening the browser if the page rendered would be a 404 (this wouldn't be great experience).

Change "open in browser" to "view in browser" for pr view and issue view

In the help for gh issue view and gh pr view we say "Open this issue in the browser." This confused someone in usability testing because they weren't sure whether "open" meant they were opening a new one or just viewing the existing one.

Ensure each command sets appropriate context and feedback

Add to gh pr create:

Creating pull request for [branch] into [master] in [repo]

Add to gh issue create:

Creating issue in [repo]

Add to gh pr list:

Open pull requests in [repo]

Add to gh issue list:

Open issues in [repo]

For each, add to the top of the command when it's run. For example:

~/Projects/my-project$ gh pr list

Open pull requests in desktop/desktop

#123	Title title titl… [branch] 		
#123	Title title titl… [branch] 		
#123	Title title titl… [branch] 		

Add `gh issue list` to master

Based on the spec in https://docs.google.com/document/d/1bkKuJN6tFrfpAsA_yuThyVVtT79CvoM5solKSrxlMRs/edit#heading=h.k8x8t8qnkons

Issue List

~/Projects/my-project$ gh issue list --help

Show a customizable list of issues

Usage:
gh issue list [flags]

Flags:
-a	Filter by assignee
-l	Filter by label
-s	Filter by state
???

Global Flags:
-B, --current-branch string   current git branch
-h, --help                    help for gh
-R, --repo string             current GitHub repository

Task list – Oct. 7th

Hi @github/ce-cli, This is a more granular task list than what is listed in Neha's demo planning doc.

If you want to share what you are working on put it on the list and put your name next to it. If you are looking for what to do next, find something that isn't claimed and is on this list!

• [prototype] gh pr checkout
• [prototype] gh pr list
  • [prototype] CI status @mislav
  • [prototype] Requested changes @mislav
• [master] Move graphql code to master @probablycorey
• [master] Add tests for some of the PR commands @probablycorey
• [master] Add generic error handling pattern
• [master] Reimagine how the app determines its context #2 @vilmibm
• [master] Incorporate the stable parts of last weeks demo _this task is still too open-ended and @probablycorey wants to talk about it at our fortnightly sync

Add `gh pr create` to master

• tests
• clearer errors
• clean up flag parsing (switch to non-package-var style)

Add user friendly error message for incorrect command

Describe the bug

When typing a command incorrectly, Graph QL spit out an error message that was not relevant for the end user.

gh issue list -a tierninhods = misspelled handle

graphql error: 'Something went wrong while executing your query. Please include `EEE3:880B:79ACD6:93DDE0:5DE84F43` when reporting this issue.'

Perhaps we could swap this to something else? I suspect there are other instances buried in the code that would produce something similar. Will update the thread as needed.

Reimagine how the app determines its context

The app currently determines the context it's operating under from several sources:

• the filesystem (e.g. current directory name)
• app config file (currently ~/.config/hub in YAML format)
• environment variables (e.g. GH_REPO, GITHUB_TOKEN, etc.)
• git config (via git config & git remote -v, sources: .git/config & ~/.gitconfig)
• git tree (e.g. current branch, current commit SHA)
• SSH config (sources: ~/.ssh/config & /etc/ssh_config) - resolves SSH aliases for hostnames listed under git remotes
• GitHub API (e.g. info about the current repo)

When something like gh pr create gets run, quite a lot happens under the hood. For example:

1. Current GitHub user and OAuth token are obtained from app config;
2. The list of git remotes gets queried and parsed;
3. The "main" remote (i.e. one pointing to the canonical GitHub repo) is determined by searching for the first one in this list: upstream, github, origin;
4. The base branch is determined via git symbolic-ref refs/remotes/<REMOTE>/HEAD (alternatively, by querying repo information via API);
5. The head branch is determined by looking at the push target for the current branch:
   • explicit upstream branch configuration is first looked up;
   • otherwise, the first remote that has a same-named tracking branch is the likely push target;
   • otherwise, assume the branch isn't pushed yet, so determine the first remote that points to a GitHub project that the current user has write capabilities to;
   • if such a remote doesn't exist, create one by forking;
6. A person's preferred text editor is looked up for authoring PR description text;
7. PR creation operation proceeds.

To facilitate all these lookups, the current codebase has a loose system of mapping one piece of information to another. For example:

• current git repo 👉 default ("base") branch
• current git repo 👉 "main" remote
• git remote 👉 GitHub repository (a.k.a. "project") it maps to
• tracking branch 👉 git remote it belongs to
• current user 👉 the person's fork

Since a lot of lookups start from the current git repo (based on the current working directory at the time that the CLI app runs), there is a LocalRepo struct that encapsulates performing some of these mappings, while additional mapping logic is scattered across individual methods such as Branch.RemoteName(), Remote.Project(), etc. Some problems I find with the current system:

• Inconsistent naming (e.g. "repository" vs. "project", the ambiguity of "branch")
• Blurred responsibility between objects (e.g. why would a Branch have to know how to map itself to a Remote, or a Remote to a Project?)
• Methods that do too much but don't sufficiently betray intent (e.g. LocalRepo.RemoteBranchAndProject())
• Hard to stub out in tests (ideally, unit tests should be able to set up a mock context in memory rather than having to write a test git repo out to fileystem)
• All of this code is under the same Go package: "github".

My rough proposal for starting to address this:

• Get rid of methods and structs named "Project" from the codebase;
• Get rid of LocalRepo;
• Design an abstraction around git config that is able to mock responses in memory;
• Consider moving github/branch.go to under the "git" package;
• Consider isolating git/ssh_config.go to its own package;
• Minimize the implementation of Remote and instead perform necessary mappings through a separate service object;
• Minimize the "github" package until it's ideally gone;
• Write Go unit tests along the way to confirm the testability of these implementations.

Let's revise all this as we go along! Thank you for reading. 🙇

Evaluate current help pages

• What order should the commands go?
• How do we display flags?
• How should we describe each command?

Issue titles are being divided into two lines

Describe the bug

Issues titles are being split between two lines in CLI. I believe the cause is a bug on dotcom where the rendered version of the title does not match the input. For example, a title is rendered as "1word 2word" but when you click edit, the title shows as "1word2word".

Real world example: tierninho/PRlist1#40

gh version 0.3.1 (2019-12-04T18:49:39Z)

Steps to reproduce the behavior

Unsure.

Add a project board

Look, I created a project board https://github.com/github/gh-cli/projects/1.

If there is something you want to change let's talk about it in this issue. Here is some justification for why I set it up like this.

To do: I've used this column to figure out what to do next. Depending no how "agile" the project is, I've also had a backlog column where we put things we want to put into the next sprint. I've defaulted to simplicity and left this out for now.

In progress: This column is used to let teammates know that you are working on an issue and for people to get a glance of what is being worked on. I usually assign myself to the issue to because it easy to visually see who is working on what

Needs review: This column is used to signal that a PR is done and you want your teammates to look at it.

Needs to be merged: This is a placeholder column for PRs that are good to go but haven't been merged.

Done: I'll give you one guess what this is for.

Associate default labels with a terminal color

In #58, @probablycorey mentioned that color alone wouldn't be very sustainable. It would be nice to have a consistent design language to display them

---

Update:
At our brainstorm, we talked about proxying the default label colors to the terminal colors above as a start!

Ensure that update notifier doesn't check for new releases too often

Reword descriptive text if all issues are open

If you have no closed issues and you type: gh issue list --state closed, you get: There are no open issues.

This should be updated to: There are no issues found. or similar as the issues are not "open".

gh version 0.3.1 (2019-12-04T18:49:39Z), OSX

(PS- I checked gh pr list --state closed and is does not do this.)

Align `gh issue create` with `gh pr create`'s interface

issue create takes data on STDIN. In order to support issue templates and syntax highlighting, it should be ported to use the survey+EDITOR approach of pr create now that pr create is merged.

Cannot download and install CLI on Mac

Describe the bug

Removed CLI from my oAuth in Github.com settings and then tried to reinstall CLI, but an exception occurred.

➜  ~ brew install github/gh/gh
==> Installing gh from github/gh
==> Downloading https://github.com/github/homebrew-gh/releases/download/v6.6.6/gh_6.6.6_macOS_amd64.tar.gz
#=#=-#  #
curl: (22) The requested URL returned error: 404 Not Found
Error: An exception occurred within a child process:
  DownloadError: Failed to download resource "gh"
Download failed: https://github.com/github/homebrew-gh/releases/download/v6.6.6/gh_6.6.6_macOS_amd64.tar.gz

Steps to reproduce the behavior

1. Remove oAuth in Settings
2. Ran brew uninstall github/gh/gh
3. Attempt to reinstall

Not sure how to reinstall and re-auth.

gh pr testing results

Testing results for gh version 0.0.0:

gh pr list

Test	cmd	Result	Note
basic command	gh pr list	shows all three areas; includes PR number, title, status, and CI check	✅
half command	gh pr	Shows list of PRs to select	✅
alpha-numeric	gh pr list 11 or gh pr list aaaa	still shows all three areas	on the fence about this
current branch	gh pr list	PR is shown	✅
PR created by you	gh pr list	PR is shown	✅
code review request, open/draft PR	gh pr list	PR is shown	✅
code review request, closed PR	gh pr list	You have no pull requests to review.	Should still show?
git equivalent	git pr list	git: 'pr' is not a git command. See 'git --help'.	✅

gh pr checkout

Test	cmd	Result	Note
basic command	gh pr checkout	Shows list of PRs to select	✅
closed PR, branch active	gh pr checkout 1	goes to branch of PR	Should we show if closed?
closed PR, branch deleted	gh pr checkout 1	exit status 128	better messaging
open PR	gh pr checkout 7	goes to branch of PR	✅
invalid PR	gh pr checkout 5555	HTTP 404	✅
alpha characters	gh pr checkout abcd	Error: strconv.Atoi: parsing "abcd": invalid syntax	better messaging
git equivalent	git pr checkout	git: 'pr' is not a git command. See 'git --help'.	✅

gh pr show

Test	cmd	Result	Note
basic command	gh pr show	opens PR in browser	✅
add valid number	gh pr show 2	opens PR or issue in browser	Still open if an issue?
add invalid number	gh pr show 222	opens 404 browser	Verify in cmd line is better
add alpha	gh pr show 2	Error: invalid pull request number: 'dfsd'	✅
git equivalent	git pr show	fatal: ambiguous argument 'pr': unknown revision or path not in the working tree.'	✅

gh pr create

Test	cmd	Result	Note
basic command	gh pr create	asks for PR Title	✅
PR Title left blank	gh pr create, [enter]	Moves to PR body field	block a blank entry as ends up with HTTP 422 later
PR Title with text	gh pr create, enter some text	moves to PR Body field	✅
PR Body with text, PR does not exist, has commits	gh pr create, [enter], add text	PR submitted	✅ , add option to open in browser?
PR Body with text, PR does not exist, no commits	gh pr create, [enter], add text	HTTP 422 error	block this from get-go
PR Body with text, PR already exists	gh pr create, [enter], add text	HTTP 422 error	block this from get-go
PR Body left blank	gh pr create	asks for PR Title	✅
Exit	Ctrl-C	Yes, Edit, Cancel and discard	all work fine ✅
git equivalent	git pr show	git: 'pr' is not a git command. See 'git --help'.	✅

gh help

Test	cmd	Result	Note
basic command	gh help	all help suggestions	✅
rubbish command	gh dfsdfsdfsdfsd	Run 'gh --help' for usage.	✅
help for help	gh help --help	specific help suggestion	✅
help for PR list	gh pr list --help	specific help suggestion	✅
help for showing PR	gh pr show --help	specific help suggestion	✅
help for creating PR	gh pr create --help	specific help suggestion	✅
git equivalent	git help	Git help suggestions	✅

`issue status` should only show open issues

Right now it's showing closed issues, while I would expect it to only show open issues

Add flag to `pr view` and `issue view` to view in terminal instead of browser

Use gh [pr or issue] view [-t or --text] to output the title and body

GitHub CLI works on Windows

I should be able to download and use GitHub CLI from my Windows machine.

Overall: evaluate parity of master with design spec

This is basically a task to create more tasks 😆

Receive error when viewing closed or merged PRs

If I try gh pr view [number] on a PR that's closed or merged, it outputs Opening in your browser. and opens my file menu.

Better error messages when you don't supply an arg

• Better error messaging when you don't supply an arg to:
  • gh pr checkout
  • gh pr view
  • gh issue view

`issue status`: sort by recency and display timestamp

At a brainstorm today, we decided we'd improve issue status in 2 ways:

• Sort sections by most recently updated
• Display a updated timestamp: "1 min ago" in gray

~/github/test$ gh issue status
Issues assigned to you
  #8 bleep bloop (bug) 1 min ago
  #1 test 5 days ago

Issues mentioning you
  There are no issues mentioning you

Issues opened by you
  #16 testing cli 2 sec ago
  #14 bleep 2 hr ago
  #13 Testing! (bug) 1 week ago

Tasks week of 10/21

Hi @github/ce-cli, This is a more granular task list than what is listed in Neha's demo planning doc.

If you want to share what you are working on put it on the list and put your name next to it. If you are looking for what to do next, find something that isn't claimed and is on this list!

• [prototype] gh fork @probablycorey
• [prototype] push + create PR linkage @probablycorey
• [prototype] basic issue support
• [master] Incorporate the stable parts of last weeks demo.
  • [master] gh pr create @vilmibm
  • [master] gh pr checkout id|branch
• [master] Continue with Context work @mislav
• [master] oauth flow polish @mislav
• [master] Present helpful errors to users (instead of the cryptic errors we see now)

Change "Recent issues" section in `issues status` to "Issues opened by you"

We thought this made more sense to have alignment with pr status and to reduce redundancy with issue list

Auth flow broken on Windows

A few things are either weird or broken when trying to auth GH on windows:

• there is a reported error trying to open a browser and a message about opening the URL manually, but the browser does indeed open and go to the correct page.
• The connection to the temporary local webserver fails, meaning you can't complete the flow. It's trying to connect on port 80. gh.exe just hangs until it's killed.

Help doesn't reflect the ability to use URL and branch name instead of issue/PR number

For example, gh pr checkout <pr-number> [flags] should show that you can also use branch name and the pull request URL

Notify users when update available and allow them to update

Users should have some way of learning when there's an update available and it's obvious how they go about updating.

test test test

Initial in-product experiment

We've discussed a lot of generative ideas here but final ideas and plans TBD