Changes
The rail on the right of the window holds the selected worktree’s working-tree changes. It has two tabs — Changes and Rebase — and the Changes tab is where staging and committing happen.
Clicking a commit in the graph swaps the tab to that commit’s files instead; ‹ Changes goes back to the working tree.
Staging and unstaging
Changes are listed as Staged and Unstaged, each with a count, and each file carries a one-letter status:
| Status | Meaning | Status | Meaning |
|---|---|---|---|
| M | Modified | C | Copied |
| A | Added | U | Conflicted |
| D | Deleted | ? | Untracked |
| R | Renamed |
Stage a file with +, unstage with −, and use the section action to move everything at once. Clicking a file opens its diff.
Untracked files are grouped by folder, and a folder holding more than ten new files starts collapsed — an untracked build directory would otherwise bury everything else in the list. You can stage, discard, or ignore a whole folder from its row.
Files with image content show a preview. The list refreshes live as files change, including when something outside PwrGit changes them.
Staging is per file. There is no line-level or hunk-level staging — see Not yet.
On a very large change set the list is capped for rendering, and says so. Actions that operate on everything — discard all, in particular — still count the real total rather than what fitted on screen.
Commit — and which identity signs it
Type a summary and press Commit. It stays disabled until there is both a message and at least one staged file.
Below the button, the rail reads as <email>. That is the
active profile’s commit email, and it is the address this commit
will be authored with.
PwrGit applies that identity per commit. It does not write
user.email into the repository, so nothing on disk changes when
you switch profiles, and a repository you commit to from two
profiles gets the right address each time. See
Profiles.
Amend
Amend rewrites the previous commit with what is currently staged, rather than adding a new one.
Amending changes the commit’s SHA. If the original was already pushed, the branch will read as diverged from its upstream afterwards — see When the branch has diverged.
Discard, and add to .gitignore
Right-clicking a file offers Stage / Unstage, Copy path, Discard changes…, and — for untracked files and folders — Add to .gitignore.
Discard all is available for the whole worktree. It confirms first, names how many files it will affect, and says plainly that it cannot be undone. Discarded changes do not go to a trash; they are gone.
The ignore action writes the right entry for the target: a file gets a path, a folder gets the folder. PwrGit tells you when the path was already covered by an existing rule instead of adding a redundant line. On a large untracked set it also points out the folder most worth ignoring.
Squash and reorder commits
Select two or more commits in the graph and a selection bar appears with Squash and Reorder. Either opens the Rebase tool in the rail.
The flow is deliberately three steps:
- Plan. The tool shows the exact step list —
pick/squash— in the order it will execute. Squash produces one commit whose message is built from the selected subjects. Reorder reverses the selected history, and the plan is shown in execution order. - Check in isolated copy. The plan is run against a throwaway copy of the worktree, reporting Clean or Snag. Your actual worktree is not touched by this step.
- Apply rebase. Enabled only after a clean check.
Hooks, signing, and rerere are disabled for both the check and the apply, so a commit hook cannot fire twice or block the dry run. Other repo-local git settings can still affect the apply.
Nothing is pushed. A rebase rewrites local history; sending it anywhere is a separate, explicit push.
Not yet
- No line-level or hunk-level staging. Staging is whole files.
- No conflict resolution UI. Conflicted files show status U; resolving them is a job for your editor.
- Squash and reorder only. The rebase tool does not offer reword, drop, edit, or an arbitrary interactive rebase.
- No stash. With worktrees, the usual reason to stash — needing a clean tree to switch branches — does not arise.