The Toolbar
The toolbar is the thin row that sits just below the header of the Git panel. It carries the controls you reach for most often — a mode toggle, the three remote actions (Pull, Push, Fetch), and a read-only label showing which branch is currently checked out.
Layout
From left to right the toolbar contains a mode toggle, a divider, three remote action buttons, a flexible spacer, and the active branch label:
- •Overview / Commit mode toggle: two small buttons labelled Overview and Commit. Clicking Commit switches the panel into Commit Mode (a dedicated file picker plus commit form, covered in its own sub-section). Clicking Overview brings you back to the normal section view. Only one of the two is highlighted at a time — the active mode.
- •Pull: downloads new commits from the configured remote for the current branch and integrates them into your local history. Disabled when the repository has no remote yet.
- •Push: uploads your local commits on the current branch to the configured remote. Disabled when there is no remote.
- •Fetch: refreshes remote-tracking information (remote branches, ahead/behind counts) without touching your working tree. Always available once any remote operation is configured.
- •Active branch label: on the far right, reads Active: followed by the currently checked-out branch name (for example Active: main). This is a read-only indicator — switching branches happens from the Branches section.
While any remote operation is running — Pull, Push, Fetch, or an operation triggered from Commit Mode — all three remote-action buttons are disabled and dimmed so you cannot start a second concurrent operation on the same repository.
Success and Failure Feedback
Every toolbar action gives you a clear outcome without having to inspect the repository manually afterwards:
- •On success: a short toast notification appears in the corner of the app — Pull completed, Push completed, or Fetch completed.
- •On failure: a dialog titled Pull Failed, Push Failed, or Fetch Failed opens with the underlying error message, so you can read what went wrong and close the dialog to try again.
Push into a Repository with Unrelated History
A common case when connecting an existing group to a brand new remote: the remote was created on the hosting provider and initialized with a README (or a LICENSE, or anything else), while your local group already has its own commits. The two histories share no common ancestor, which is normally a blocker.
When this happens on Push, Tigrister shows a dialog titled Unrelated History Detected explaining the situation and offering a Merge & Push action. Confirming it merges the two unrelated histories and pushes the result in a single step. The message in the dialog reassures you that "Tigrister only manages spec and environment files — all other remote files will be preserved", so a pre-existing README or LICENSE file on the remote is kept as-is in the merged history.
Cancel closes the dialog without touching anything. Nothing is pushed in that case.
Push When the Remote Has Moved Ahead
A second case: your local branch has commits to push, but someone else has also pushed commits to the same remote branch in the meantime. A plain push would lose those remote commits, so Tigrister stops and shows a dialog titled Remote Has Newer Commits with three clearly labelled choices:
- •Pull Now: the safe option. Pulls the remote commits, integrates them with your local commits (resolving any conflicts in the built-in merge view if needed), and leaves you with both sets of changes present locally. You can push again afterwards.
- •Force Push: the destructive option. Overwrites the remote branch with your local branch. Because this is irreversible, picking Force Push does not run immediately — it opens a second Force Push confirmation dialog warning you that "Remote commits that don't exist locally will be lost" and asking you to confirm once more.
- •Cancel: dismisses the dialog and does nothing. You stay on your current state, free to inspect the history section or switch branches before deciding.
Missing Credentials on a Remote Operation
If you trigger Pull, Push, or Fetch and the operation fails because no token is stored for the remote's host, Tigrister opens a Token Requireddialog. The dialog shows the host name it needs a token for (for example Host: github.com) and provides a single password-style input where you can paste your personal access token.
Pressing OK saves the token into the OS keychain against that host and immediately retries the original operation. If the retry still fails — expired token, wrong scope, revoked token — the dialog stays open and shows the retry error inline, so you can correct the token without having to start the operation over.
The same dialog appears from Commit Mode when a Commit & Pushaction fails for credential reasons — the commit itself always succeeds first (it does not need credentials), and only the push step triggers the dialog.