Recover from auth and lock errors
Fix authentication from the error itself, clear a stranded index.lock safely, and see why a panel or repository failed instead of an empty view.
When a git operation fails, GitLane now tells you what went wrong and, for the two most common failures, offers the fix on the error itself: a credential problem and a lock file a crashed git process left behind. Panels that can't refresh say so instead of looking empty.
Fix an authentication failure
- When a fetch, pull, or push is refused for credentials, the error toast names the remote and the problem — for example, that credentials are missing or invalid for a given account.
- Click Fix authentication… on the toast. Settings → Accounts opens, on that forge's sign-in when GitLane can tell which host failed.
- Sign in again, or pick a different account for the remote under Repository settings → Remote access (see A GitHub account for each remote), then retry.
Fetch keeps going when one remote's credentials fail. If several remotes have problems, the toast starts with "Some remotes need attention:" and gives one line per remote.
Clear a stranded index lock
Git writes .git/index.lock while it updates the index. If a git process crashes, the lock stays behind and every later stage, commit, or checkout fails.
- The failed operation's toast says a lock file exists and offers Remove lock & retry.
- Click it. GitLane checks the lock before touching it: if nothing is holding it, it deletes the lock and runs your operation again.
- If the lock is still in use, GitLane leaves it alone and tells you why — it's only a few seconds old, or a process still has it open. Wait for that git process to finish and try again.
When a panel can't refresh
A background refresh that fails no longer blanks the panel. Worktrees, stashes, remotes, and the operation status keep showing their last good data, and you get one warning toast — "Couldn't read worktrees", for example — that clears itself once a later read succeeds. The affected row or banner is marked Unavailable or "Couldn't read…", with the error as its tooltip.
If the commit history itself can't load, the history view says History unavailable and offers Retry.
When a repository has moved
Opening a repository that isn't where GitLane left it now tells you which of two things happened:
| Screen | What it means |
|---|---|
| This repository can't be found | The folder is gone, moved, or on a volume that isn't mounted |
| This folder is no longer a repository | The folder exists, but its .git is gone |
Both offer Locate…, Retry, and Remove. The second also offers Initialize as git repo, after a confirmation.
Good to know
Remove lock & retry deletes only the open worktree's
.git/index.lock, and only when the lock is at least three seconds old and no process has it open. A lock that is still in use is never removed.
On macOS and Linux, GitLane checks for open handles with lsof; without lsof, a lock is never treated as stranded, so you would remove it yourself. Lock recovery also works on Windows.
Recovery only acts on the repository that failed. If you've switched to another tab since the error, the action does nothing and asks you to switch back first.
Fix authentication… opens the app-wide Accounts settings, not the repository's Remote access page.
Shipped in GitLane v2.3.2; per-remote fetch errors and Windows lock recovery arrived in GitLane v2.3.9.
Installers: Download GitLane.