Data Protection
Five layers of defense against losing work, plus preflight checks and error handling
A core principle of GitBor is never to lose your work, even if the app crashes mid-operation. Protection is built in five independent layers — if one didn't kick in, the next one does.
1. Reflog: HEAD movement history
Git's built-in mechanism: every move of HEAD (commit, checkout, reset, rebase, merge) is logged and kept for about 90 days. GitBor relies on it for recovery. View and restore from it via Repository → More → Reflog… — see the Reflog page for the full UI.
2. Auto-stash before destructive operations
Before every pull, merge, rebase and branch-switching checkout, GitBor:
- Checks for uncommitted changes.
- If any — auto-stashes them with a marker name.
- Runs the main operation.
- On success — restores the stash; your changes are back in the working copy.
- On failure — leaves the stash in the list so you can apply it manually (Pop in the toolbar, or Apply stash from the error dialog).
So even if you forgot to commit and hit Pull, your edits aren't lost.
3. Save point before rebase and reset
Before a rebase or reset, GitBor records the current HEAD. If you don't like the result, there's a known-good point in the reflog to return to in one click.
4. Operation journal
Every destructive operation is written to a per-repo journal in three stages:
| Entry | When |
|---|---|
| Start | Before the operation begins. |
| Success | After it completes. |
| Failure | On error, with details. |
If GitBor is hard-killed between "start" and "success" (power loss, kill -9, BSOD), the journal is left unfinished — and GitBor raises it on the next launch.
5. Recovery on startup
When opening a repository GitBor checks for:
- Stale
index.lock— a leftover.git/index.lockfrom a crash. GitBor marks it stale and ignores it, but does not delete it automatically (another git process might be running). Remove it manually if it's genuinely in the way. - Unfinished journal operations — a dialog: continue, abort, or forget.
- Unfinished rebase — restores the progress banner with Continue / Abort.
- Unfinished merge — opens the merge editor for conflicting files.
Error handling and preflight checks
Before risky operations GitBor runs preflight checks and, when something is wrong, shows a focused dialog with the cause and the right next step instead of a raw Git error. Common cases:
| Situation | What GitBor offers |
|---|---|
Another git process holds index.lock | Wait, Kill git process, or Remove index.lock — with the list of running git processes. |
| Working tree would be overwritten | Stash, commit or discard first. |
| Merge / rebase / cherry-pick / revert already in progress | Continue or abort it before starting another. |
| Unresolved conflicts in the index | Resolve them or abort first. |
| Remote rejected push (non-fast-forward) | Pull or rebase before pushing. |
| Network / authentication failure | Retry, or fix your connection / credentials / SSH key. |
| Untracked files would be overwritten | Move or remove them first. |
When an auto-stash was created during a failed operation, the dialog tells you its hash and offers Apply stash to recover.
Input and settings safety
Beyond repository data, GitBor guards against bad input:
- Paths from Open / Clone are validated — attempts to escape the chosen folder (
../../etc/passwd) are rejected. - Risky roots (home, drive root,
Program Files,node_modules) open without the file-change watcher, to avoid hammering the OS. - SSH key and hook filenames are checked for special characters.
- Secrets in the log (password flags and similar) are masked before being written.
- Settings and caches are written atomically — temp file then rename — so a power cut mid-write can't leave a broken config.
- AI keys are encrypted via the system keychain.
If something does break, the reflog and the journal are still there. It's very hard to lose anything already committed in Git; GitBor adds protection for the uncommitted parts too.