Issues and Pull Requests

Issues & PRs (Ctrl+1) lists a repository’s issues and pull requests together, newest first, like an inbox. It is what you see when you open a repository.

Each row shows the number, whether it is an issue or a PR, its state (OPEN, CLOSED or MERGED) and its title. Other columns are available under View → Columns; see List Mode, Sorting and Columns. The status bar counts what loaded: “owner/name — 23 issues, 7 PRs (open). Showing up to 100 newest.”

The details panel shows the item in full: state, author, dates, address, labels, assignees and comment count; for a pull request whether it is a draft, whether it is merged, its review status, its branches and the size of its changes; then the description and every comment. Alt+N and Alt+P move between the comments. See The Details Panel and Comment Navigation.

Choosing what is listed

View → State shows Open, Closed or All. Open is the default.
View → Filter shows Issues Only, PRs Only, or Issues & PRs.

Both reload the list from GitHub, so they reach items that were never in the list you had.

Keys in the issues list

Key	Action
`Enter`	Open the issue or pull request on GitHub in your browser
`C` or `Ctrl+W`	Close it
`O` or `Ctrl+Shift+W`	Reopen it
`M` or `Ctrl+M`	Add a comment
`N` or `Ctrl+N`	New issue
`F`	Add it to favorites, or remove it
`Ctrl+G`	Go to an issue or pull request by number
`Ctrl+O`	Open it on GitHub

Closing and reopening ask first, naming the item: “Close issue #12?” with its title. A comment is typed into the Add Comment box, which takes several lines. When the change has gone through, the status bar says so, for example “Closed #12. Refreshing…”, and the list reloads.

Creating an issue

Actions → New Issue… (Ctrl+N, or N in the issues list) opens a form with a title and a description. Write the description in Markdown, as on github.com. Enter in the title moves on to the description. In the description Enter starts a new line, so Ctrl+Enter (Cmd+Enter on a Mac) creates the issue from anywhere in the form, as does the Create Issue button; Tab moves between the fields, and on Windows Alt+T and Alt+D jump to them.

New Issue works wherever you are, for the repository in front of you:

in a view of the open repository, that repository;
with focus in the repository list, the repository selected there;
in Notifications, My Work, Activity, search results, Starred, Watched or Favorites, the selected row’s repository.

When that isn’t the repository open, GHManage opens it on its issues first, so the new issue shows in its list; from Notifications, My Work, Activity, search results, Starred or Watched, Backspace afterwards comes back to where you were. With no repository in front of you, the status bar says so.

The form names the repository the issue goes to. On a fork that is the upstream repository, since that is where the issues you see in the list live.

Once GitHub has it, the issues list reloads with the new issue selected, unless you have moved to another view or repository in the meantime; then the status bar just says it was created. While one issue is being created, Ctrl+N waits for it, so the same text can’t be filed twice. If you cancel the form with something typed, or GitHub refuses the issue, what you typed is kept and Ctrl+N brings it back, until you quit GHManage.

Pull requests

On a pull request in the issues list:

Key	Action
`K`	Its checks: how many passed, failed or are still running, then each one, failures first, with its link
`V`	Review it: approve, request changes, or comment, with a message
`D`	Mark a draft ready for review, or an open pull request back to a draft, after asking

Actions → Pull Request has those three, and:

Merge… offers the ways the repository allows (a merge commit, squash, rebase) and whether to delete the branch afterwards. A draft has to be marked ready first. The status bar then says what happened: merged; or, when required checks are still running, that GitHub turned on auto-merge and will merge it when they pass; or that it accepted the merge but hasn’t done it yet, as with a merge queue. If GitHub won’t merge it at all, because a required review is missing say, the status bar gives GitHub’s reason.
Request Reviewers… takes GitHub logins separated by commas, or a team as org/team-name.
Update Branch… merges the base branch into the pull request’s branch, as the button on github.com does, after asking.

K, V and D work from the details panel too. The review form works like New Issue: Ctrl+Enter submits it from the message. Requesting changes or commenting needs a message; approving doesn’t. After a review, merge or change, the list reloads.

When a check failed in a GitHub Actions workflow, Workflow Runs (Ctrl+7) and L on its run shows what failed.

Go to an issue by number

File → Go To Issue… (Ctrl+G) asks for a number and puts you on that issue or pull request, with focus in the details panel so you can start reading. It works in Issues & PRs only.

If the number is not in the list, because it is closed while you are viewing open items or older than the list reaches, GHManage fetches it from GitHub, adds it to the list and selects it. If it is in the list but hidden by the quick filter, the filter is cleared so you can see it. If the number is neither an issue nor a pull request, GHManage says “#123 does not exist as an issue or PR in owner/name”; if GitHub could not be reached at all, it gives the real reason instead, so a dropped connection is never mistaken for a missing issue.