Forges

PwrGit reads pull request and merge request status for your branches, repository visibility marks, and commit author avatars. All of it goes through the CLI you already sign in withgh for GitHub, glab for GitLab.

What PwrGit reads, and how it signs in

PwrGit never asks you for a password, and stores no token of its own. It delegates to the CLI’s existing login. Signing out of gh signs PwrGit out too; there is no second credential to revoke, and no new place for one to leak from.

This is best-effort by design. When no forge claims a repository’s origin, when the CLI is not installed, when it is not logged in, or when the network is down, these features quietly do nothing. Nothing else in PwrGit stops working — git operations do not go through a forge.

Which forge answers is worked out from origin. The two SaaS hostnames and a gitlab.* prefix are recognized; a self-managed instance on an unrelated hostname cannot be identified with certainty, and the feature stays off there rather than guessing.

Connect GitHub

Install the GitHub CLI and sign in:

gh auth login

Settings → Forges updates on its own once you have — you do not need to reopen it, and PwrGit does not need restarting.

Connect GitLab

Install the GitLab CLI and sign in:

glab auth login

Merge requests are supported on gitlab.com and on self-managed instances. GitLab calls them groups where GitHub says organizations, and PwrGit follows whichever host you are on.

Pull and merge request status

Once a forge is connected, branches carry a chip with their change request’s number and state, and hovering it opens a card with diff size, commit count, branch names and timestamps.

Three things are worth knowing:

Status is fetched in bulk and cached, and refreshes are throttled, so a repository with a hundred branches costs a couple of requests rather than a hundred.

Commit author avatars

See History → author identity for how a commit is matched to a forge account, and why PwrGit shows nothing rather than guessing.

Both forges’ transports delegate authentication to their own CLI rather than extracting a token, so this feature never widens what PwrGit can see.

What each forge supports

Settings → Forges lists each forge’s state and its capabilities. A capability that is missing is a limit of that provider’s API, not a bug in PwrGit:

Capability GitHub GitLab
Branch status in bulk Yes Yes
Commit links in bulk Yes No — no batch endpoint
Diff size and timeline Yes Yes
Fork just the default branch Yes No — no equivalent in its fork API
Commit author avatars Yes Yes

Where a capability is absent, the UI hides the control rather than showing one that would be accepted and silently ignored — which is why the fork dialog has no default-branch-only switch on GitLab.

Troubleshooting

Settings → Forges is the first place to look. It reports each forge as Connected, Signed out, or Not installed, and names the exact command that unblocks the last two.

Symptom Cause
No PR chips anywhere CLI not installed, or not logged in — check Settings → Forges
No PR chips for one repository origin points at a host PwrGit cannot identify
Repositories show no public/private mark Same — the mark comes from the forge
“Install the GitHub CLI” while gh is installed The catalog was still loading; it settles on its own
Squash-merged branches not marked prunable Needs a connected forge — git ancestry alone cannot see a squash merge

A repository PwrGit has never successfully asked about carries no identity mark. That is deliberately different from a mark reading unknown, which means the forge was asked and would not say. Neither collapses into “public” — that would understate where your code can go.