Repositories

PwrGit indexes repositories from folders you nominate, and lists them in the sidebar. The list is meant to survive being long: lenses narrow it, pins float the ones you care about, and Command+K finds anything by name without scrolling at all.

Profiles

A profile is a workspace. It carries:

• a name — a workspace label like Acme or Personal. It appears in the window title and the Profiles menu. It is not your name.
• a commit email — the address commits are authored with while this profile is active.
• an optional author name, when the name on the commit should differ from the git default.
• a set of repo folders — see below.

Each profile opens in its own window. The Profiles menu lists them all with New Profile… and Manage Profiles…, and the first nine get Command+1 through Command+9 (Ctrl+1–Ctrl+9 on Windows). Picking a profile opens its window, or focuses it if it is already open.

The commit identity is applied per commit

PwrGit does not write user.email into a repository’s config to change your identity. It passes the profile’s identity to each commit as it makes it, which means:

• Switching profiles changes nothing on disk. No repository is left configured for a company you have stopped working for.
• A repository you commit to from two different profiles gets the right address each time, with no per-repo setup.
• Commits made outside PwrGit are unaffected — your global and repo-local git config keep whatever they already said.

The commit box in the rail reads as <email> so you can see which identity is about to sign, before it does. See Commit.

Repo folders

PwrGit does not scan your disk uninvited. Each profile has a list of repo folders, and PwrGit searches those — to a bounded depth — for git repositories. It skips repositories vendored inside dependency directories, so a node_modules tree full of checked-in .git folders does not flood the list.

Add folders from Add folders… at the top of the sidebar, or from Settings → Profiles → Edit…. A profile with no folders can do nothing else: Clone… and Fork… stay disabled until one exists, because both need somewhere to put the result.

Repo folders are also what makes a repository belong to a profile — a checkout under ~/work shows up in the profile whose folders include ~/work.

The sidebar

The sidebar is a tree: repositories at the top level, each expanding into the worktrees checked out from it. Selecting a worktree is what drives the rest of the window.

• Pins. Repositories and worktrees pin independently, and pinned items sort first. A repository also appears in the Pinned lens when one of its worktrees is pinned, not only when the repository itself is.
• Arrangement. Drag pinned repositories to order them, or use Command+Shift+Up / Command+Shift+Down from the keyboard. The arrangement is remembered per profile.
• Worktree sort. Each repository has its own sort, cycled by the control on its row: Recent → Pinned → A–Z → Active. A drag-reorder inside a repository wins over all four and shows as Custom.
• Grouping. Sidebar display options (the ⋯ button beside the lenses) toggles Group by folder, which brackets repositories under the repo folder they came from.
• Badges. Worktree rows carry dirty, ahead and behind counts. See Reading a worktree row.
• Identity marks. Repositories show whether they are public, private or internal, and whether they are a fork. These come from the forge and need a connected CLI — see Forges. A repository PwrGit has never been able to ask about carries no mark at all, which is different from one the forge declined to describe.

The selected lens, the expanded repositories, the sort choices and the arrangement all survive a restart.

Lenses

Five filters sit above the tree. Each shows a dot when it has anything in it, and the active one spells out its count.

Pinned is the only one that is a list you own. The other four answer a question about current state and re-evaluate themselves.

Stale is the one worth knowing about — it is how you find the worktrees you finished with months ago. See Finding prunable worktrees.

Search

Command+K or Command+F (Ctrl+K / Ctrl+F) opens the search overlay, as does Jump to repo… at the top of the sidebar. Escape closes it.

It searches across every profile, not just the active one. Opening a result that lives in another profile switches to it.

What it matches:

• Repositories, by name.
• Worktrees, by branch name and by path — so a query typed from a shell prompt still finds the worktree whose branch was renamed since.
• Local branches with no worktree, and remote branches. Picking one opens the New worktree dialog rather than selecting a row, because there is nothing yet to select — a remote branch is created from the fetched ref, a local one is checked out.
• Commits, by message, and by exact SHA.

With the box empty it lists pinned repositories first. Results carry their pull or merge request chip where there is one, and you can pin from inside the overlay.

Clone

Clone… in the sidebar opens a dialog with three parts: what to clone, how to connect, and where to put it.

The source box searches your forge as you type — it does not enumerate every repository you can see first, so the dialog is usable immediately rather than after a long load. You can also type owner/name directly. A half-typed owner prefix like pwrdrvr/micro is treated as an owner-scoped search rather than an exact miss.

Clone with picks the protocol: SSH, HTTPS, or the forge’s CLI (gh / glab). The CLI option needs that CLI installed and signed in; it is disabled otherwise.

The destination box offers your repo folders and any nested prefix under them, with recently-used destinations first. Clone progress reports as it runs.

Fork

Fork… forks a repository on the forge and checks out your copy in one flow. Pick the source repository the same way as Clone, then choose:

• Where the fork goes — your own account, or an organization (GitHub) or group (GitLab) you belong to.
• The fork’s name, if it should differ from the source’s.
• Default branch only, on GitHub. GitLab has no equivalent in its fork API, so the switch is hidden there rather than shown and quietly ignored.

If the fork already exists, that is not an error — PwrGit reads the result back, so “created” and “already there” are the same path.

Remotes

A repository’s refs browser has a Remotes tab listing every remote with its fetch and push URLs, alongside a Branches tab for local and remote branches.

You can add a remote, edit one (name, fetch URL, and a separate push URL when it differs), or remove one. This works on an empty repository too — a repository with no commits still lets you add its first remote.

Remote branches page in rather than loading every ref at once, so a repository with thousands of branches stays responsive.