Coder Legion - Recent posts tagged gitwand

Why GitWand is Rust, not Electron: what native performance actually buys a Git client

Fri, 21 Aug 2026 15:52:00 +0000

It's been a while since the last post here (v3.5, July 10). Since then, three releases have shipped: v3.6.0 (a handful of workflow polish items), v3.6.6 (a pure dev-loop and CI performance pass, no product surface), and v3.7.0 (Commit Review, a local AI pass over your staged changes). A straight changelog recap would cover all three, but it would miss the thing that actually connects them.

Every one of those releases is a direct consequence of a decision made on day one: build on Tauri 2 and Rust instead of Electron, and keep the actual conflict-resolution logic in a deliberately portable, zero-dependency TypeScript package instead of folding it into the Rust backend. That split sounds like an implementation detail. It isn't. It's the reason a 5-repo Launchpad refresh takes 30ms instead of most of a second, the reason a 30-second timeout bug fixed a few days ago (#166) had a one-line fix instead of a rewrite, and the reason the new Commit Review feature never has to touch a GitWand server. This post is about that decision, with real numbers pulled straight from the codebase instead of the usual "native is faster, trust us."

The bet, and who else made it

GitWand ships as roughly an 8 MB installed binary. GitKraken, built on Electron, ships in the ~150 MB class: a full bundled Chromium plus a full bundled Node.js runtime, running alongside each other, for an app that mostly renders text and spawns git. GitHub Desktop is the same story. The gap shows up at startup (GitWand is sub-1 second) and it shows up on large repos, where an Electron app's single JS heap has to hold and garbage-collect everything the UI touches.

To be fair to the field: GitWand isn't the only one making this bet anymore. GitButler is Tauri + Rust too. GitComet skips the webview entirely and goes pure Rust with GPUI. Strand is Tauri + React. Being native, in 2026, is closer to table stakes for a new Git client than a differentiator; RelaGit is the interesting counter-example, choosing Electron even with a SolidJS frontend for its fine-grained reactivity. The real question isn't "who avoided Electron," it's what each of these tools actually does with the native layer once it has it. That's the part worth walking through.

What Rust buys: fearless concurrency, with a number attached

Rust's ownership model turns a whole class of concurrency bugs into compile errors instead of production incidents. That's a nice sentence to put in a pitch deck. Here's what it looks like in a file that ships in the app today.

GitWand's multi-repo dashboard (Launchpad) needs the status of every repo in your workspace: branch, ahead/behind, modified-file count. The naive version spawns four git subprocesses per repo, one after another. GitWand's Rust backend does two things instead: each repo's status comes from a single in-process libgit2 call rather than four subprocess spawns, and every repo in the workspace gets processed in parallel via rayon's into_par_iter(), one core per repo instead of one core doing all of them in sequence. The comment sitting next to that code in the source states the measured result plainly: a 5-repo workspace listing went from about 750ms wall-clock to about 30ms in the typical case. That's not a marketing number, it's a comment next to a #[tauri::command] that ships today.

The same pattern shows up all over the backend, because once the tool exists, using it costs nothing extra: PR +/- stat enrichment across GitHub, GitLab, Azure DevOps, and Bitbucket all fan out per-PR diff computation across cores instead of looping; submodule status checks across a repo's submodules run in parallel; per-branch top-author lookups for the branch picker do too. A few days ago, a regression brought back a 30-second gh_list_prs timeout: the per-PR stats loop had gone back to running one git diff --numstat at a time. The fix wasn't a rewrite or a new thread pool, it was swapping a for loop for .par_iter_mut(). None of these needed hand-rolled synchronization or a bespoke worker pool. The parallel version and the serial version are the same number of lines, and if two of those parallel closures ever raced on the same mutable data, that's a compile error, not a bug report from a user with a corrupted status badge.

What Rust doesn't need to buy: the conflict engine stays TypeScript, on purpose

Here's the part a "Rust is fast" pitch usually skips: the actual pattern-classification engine, the code that decides same_change versus one_side_change versus complex and merges JSON, YAML, and lockfiles key by key, is not written in Rust. It lives in @gitwand/core, and that package is deliberately zero-Node, browser-safe TypeScript.

That's not a compromise, it's a second, equally deliberate architectural line. Classifying a few hundred lines of diff text against nine pattern rules finishes in single-digit milliseconds no matter what language it's written in; Rust's raw throughput wouldn't move that number in any way a user could feel. What Rust would have cost is portability: because the engine has no Node dependency, the exact same code runs inside the desktop app, in the CLI (npx @gitwand/cli resolve), inside the MCP server that AI agents call, and could run directly in a browser tomorrow with no changes. The rule GitWand actually follows isn't "everything is Rust." It's narrower and, we think, more useful: Rust owns the boundary with the operating system (spawning git, walking the filesystem, talking to forge APIs, the whole app shell), and the deterministic algorithmic core stays a small, dependency-light, portable package that isn't tied to any one runtime.

The unglamorous release: v3.6.6

v3.6.6 shipped no new product surface at all, just a dev-loop and CI performance pass, and it's the release that best shows the bet compounding on itself. Because the entire backend is one Rust crate, the same profiling discipline used to make the app fast also applies to making the build fast: a [profile.dev] tuned for lighter debug info cut a post-edit cargo build from about 21 seconds to about 6.5. On the CI side, a desktop job that produced three fully-signed release bundles on every single push to main, bundles nobody downloaded, was replaced with a fast rust-check job (fmt, clippy, check, test) that finally runs the app's 217 Rust unit tests in CI for the first time, saving roughly 230 billed CI minutes per push. On the TypeScript side, Vitest's global jsdom environment (needed by maybe a fifth of the test files, paid by all of them) was scoped down per-file, cutting environment setup time from about 96 seconds to about 17 across the suite.

Worth mentioning: before touching any of it, every claim in the plan for this work got re-measured against the actual codebase, not assumed. Several turned out to be wrong. "Any edit recompiles and relinks everything" wasn't true, cargo check after a real edit came back in under 2 seconds; the real cost was in the codegen-and-link step of a full cargo build. "The old jsdom setup costs 100 to 300ms per file" was an underestimate by roughly 10x once actually profiled. That's the same discipline the conflict engine's confidence scores are built on: don't ship a number you haven't checked.

Commit Review, and why local-first is the real differentiator

v3.7.0's headline feature, Commit Review, runs an AI pass over your staged changes right in the Changes panel before you commit, with inline findings and a "Fix with agent" action that hands them to a terminal AI session (Claude Code, opencode, or Codex) already running against your repo. What matters about it architecturally is what it doesn't do: it never calls a GitWand-run server. The review runs against whichever AI CLI you already have installed, on your machine, over your own already-open agent session.

That's the same "zero mandatory cloud" value the conflict engine already embodies, applied to review instead of merge. It's also the sharper contrast with where a chunk of the market is headed: tools positioning code-intelligence features as a metered cloud API (Greptile's own "Genius API" is priced at $0.45 per request) are betting that developers will pay per call for something GitWand ships as a local, free, opt-in feature built on tools you already run. Being local-first for conflict resolution and local-first for review isn't two separate decisions, it's the same one, applied twice.

The small stuff: v3.6.0

Between the two, v3.6.0 shipped things that don't need an architecture section to justify: a one-click "Update branch" prompt when you check out something behind its upstream, and a non-blocking handoff when an interactive rebase hits a conflict (issue #128), so the conflict editor no longer traps you behind a modal. These are the kind of small interactions that only feel good because there's no Electron process and no garbage-collector pause standing between the click and the result. The architecture doesn't just enable the big numbers, it's also why the boring stuff feels instant.

Where the bet goes next

The roadmap's next stop, v3.9.0 (Live Repo), applies the same philosophy one layer up: a Rust notify crate watcher replaces the current 2-second status poll with real filesystem events, more read paths move to in-process libgit2, and separately, the portable TypeScript core's diff/parse hot path gets moved off the main thread into a Web Worker. Same rule, two languages: Rust handles OS-level events natively and cheaply, and the portable core gets pushed off the render thread the way any JavaScript does it. One architecture, one non-negotiable: the UI thread never waits on either of them.

The market read

The Git GUI space is splitting into two camps: Electron incumbents charging a subscription for cloud AI features (GitKraken at $8/mo, with its advanced and AI features gated behind an account), and a newer wave of native, mostly free, often open-source tools built on Rust or a comparable native stack (GitButler, GitComet, Strand, and GitWand, with RelaGit staying on Electron by choice). Being native is fast becoming the price of entry for that second group, not what sets any one of them apart. What actually differentiates GitWand inside it is what the native layer gets used for: a conflict-resolution engine that classifies instead of guesses, multi-repo workflows that get genuinely (and measurably) faster because of how the backend is built, and an AI layer that never assumes your code should leave your machine.

Download GitWand for macOS, Linux, or Windows from GitHub Releases, read the full changelog, or see how the numbers stack up against specific tools on the compare pages.

GitWand from v1.6.3 to v3.2.0: the merge engine gets structural, the workflow gets multi-forge

Fri, 03 Jul 2026 18:24:54 +0000

Back in April I wrote about why GitWand exists: most Git clients show you a conflict and stop, and I wanted one that actually understood the structure of what it was looking at. That article left off at v1.6.3 — the pattern registry, the merge preview, the CLI and MCP server, 322 tests. Since then the project has shipped roughly two dozen releases, and rereading the changelog end to end, three things stand out: the conflict engine went from pattern-matching text to parsing actual syntax trees, the app stopped assuming GitHub is your only forge, and the whole thing got noticeably faster under the hood. Here's the detailed version.

The conflict engine: from text patterns to ASTs to a validated LLM fallback

The nine-pattern registry from April was already good at the trivial 60-80% of conflicts, but anything involving real code structure — a rename, a moved function, a reordered block — still fell through to complex. Three releases changed that.

v2.1.0 replaced the underlying diff routine with Histogram diff (rare-anchor splitting with forward/backward extension, the same approach JGit uses), which on its own lifted the success rate of the non_overlapping and insertion_at_boundary patterns on real source code. It also shipped a primitive block-move detector using Rabin-Karp rolling hashes with token-diversity filtering — no scoring impact yet, but it laid the groundwork for what came two versions later.

v2.2.0 added a format-profile registry to the JSON and YAML resolvers. Instead of treating every array as an opaque blob, JSON Pointer paths like /dependencies or /scripts get a merge strategy (set-by-identity or merge-keys), and YAML sequences in Helm values or Kubernetes manifests merge by name or port instead of bailing out on a single divergent line. Five built-in profiles ship (package.json, tsconfig.json, composer.json, helm/values.yaml, generic Kubernetes manifests), and underneath it there's a minimal in-house RFC 6902 JSON Patch implementation — diffJson, applyJsonPatch, mergeJsonPatches — with the round-trip property verified against 100 random JSON inputs.

v2.3.0 is the big one: an AST-based first pass using web-tree-sitter for TypeScript, TSX, JavaScript, JSX, Python, Go, and Rust. Base/ours/theirs get parsed, top-level entities (functions, classes, methods) are paired by canonical signature, and the merge happens entity-by-entity — the same approach Mergiraf and Weave use. When the structural pass returns null, the hunk-based engine takes over, so coverage never regresses. It stays browser-compatible by treating web-tree-sitter as an optional peer dependency and loading grammars lazily through three environment adapters (Node, browser, Tauri), so the package keeps zero static Node imports.

v2.6.0 built on the block-move detector to add refactoring-aware merging: a four-phase pipeline that tokenizes base/ours/theirs, identifies tokens that vanished from one side and appeared on the other, and confirms the mapping via a full bijective substitution check. It handles local variable/parameter renames, top-level function/class renames, and method moves between classes — inverting both branches back to the base naming, merging with the standard engine, then replaying the rename forward. It's opt-in (refactoringAware: { enabled: true }) and silent/zero-overhead when off. A neat edge case fix in the same release: when two parameters are renamed simultaneously with the same occurrence count, the original algorithm misclassified it as ambiguous — the fix uses permutation search over same-count candidate groups instead.

Finally, v2.4.1 added semantic validation across the board: every candidate resolution is fed through tree-sitter for its language, and anything that would produce a parse error is retried or surfaced as manual instead of silently shipped. A new postMergeRisk dimension (weight −0.20) demotes the confidence score retroactively. Validation now runs in three tiers — off, balanced (the new default, parse-tree check only), and strict (adds tsc --noEmit and eslint via a dedicated adapter).

On top of all that structural work, v2.5.0 introduced an opt-in LLM fallback for whatever's still classified complex. You supply any endpoint that accepts a prompt and returns a string; GitWand builds a context-aware prompt from a configurable window of surrounding lines, calls it, and only accepts the result if it clears a minPostMergeScore threshold after being run back through the parse-tree and post-merge scoring pipeline. Below threshold, it degrades cleanly to complex for manual review. Every accepted resolution is tagged llm_proposed in the decision trace, with the full audit trail — model, latency, prompt hash, truncated raw response, validation score — attached as an LlmTrace. Critically, the synchronous resolve() never touches the model; only resolveAsync() does, so nothing about the default performance profile changed. It took until v2.8.3 for this to actually be wired into the desktop app, CLI (--llm-fallback, --llm-provider, --llm-model), and MCP server (a gitwand_resolve_hunk tool that inverts the flow — the connected agent is the LLM) — validated against a 15-fixture benchmark where all fixtures resolved through llm_proposed with a validation score of 100.

Multi-forge support: GitLab, Bitbucket, Azure DevOps

v2.10.0 added native GitLab support (via the glab CLI) and Bitbucket Cloud support (via the REST v2 API directly, no CLI needed), bringing diffs, CI status, inline comments, and draft-to-ready conversion to all three forges uniformly. v2.14.0 filled in the remaining gaps: GitLab inline comments now anchor to the exact diff line through the Discussions API (passing base_sha/start_sha/head_sha from the MR's diffRefs) instead of landing as general notes, Bitbucket got CI checks via the Pipelines commit-statuses endpoint and a title-prefix convention for draft PRs, and comment editing/deletion was extended to all three forges.

v2.19.0 added Azure DevOps as a fourth forge, using the same Entra ID device flow with automatic token refresh, plus the full PR lifecycle, threaded comments, branch-policy CI checks, and reviewer votes. The same release replaced the GitHub CLI dependency for authentication with a built-in OAuth device flow — approve once in the browser, token goes straight into the OS keychain, never touching the frontend — and added cross-fork PR support (targeting upstream by default when your origin is a fork). v2.18.0 layered CI annotations directly into the diff view across all three forges (GitHub check-runs, GitLab code-quality reports, Bitbucket report annotations) — a warning icon in the gutter, no configuration needed if your pipeline already publishes them.

Workspaces, worktrees, and monorepo scoping

v2.7.0 introduced a workspace config file for grouping repos into a single multi-repo dashboard (fetch/pull/status across all of them), alongside a Hooks manager (toggle, create, delete any of the 18 standard Git hooks, using the .disabled suffix convention Husky understands) and first-class worktrees (one shortcut creates the branch, the worktree, and opens a tab). v2.8.2 parallelized the six workspace-wide aggregate commands using Rust's rayon work-stealing pool, so a ten-repo workspace scales roughly an order of magnitude better than a two-repo one.

v2.21.0 addressed a different scaling problem: monorepos where the commit graph is noisy with commits from packages you don't care about. A scope picker auto-detects sub-workspaces from six formats (pnpm, npm/yarn, Cargo, Nx, Turborepo, Go), all parsed natively in Rust, and narrows the commit graph, search, and stats to the selected sub-tree, with the choice persisted per repository.

The Launchpad becomes Today, and AI agents become something GitWand watches

The cross-repo dashboard first shipped in v2.9.0 as the Launchpad, with four tabs (WIP, PRs, Issues, Team) and pin/snooze support with localStorage persistence. v2.15.0 replaced the flat commit log with the Git Tree as the primary navigation surface — a full multi-branch DAG with trunk-pinning, a lane-cooldown algorithm to keep long-running projects from growing unboundedly wide, and an automatic WIP node showing uncommitted changes live at HEAD. v2.24.0 removed the permanent sidebar entirely in favor of a floating dock.

v3.0.0 rebuilt the dashboard again, renaming it Today and reorganizing it around three urgency tiers (needs you now, waiting on others, low priority) with a single context-aware primary action per item that routes directly to the right surface instead of linking out to the browser. The same release published the VS Code extension to the Marketplace as a self-contained VSIX (bundling the core engine via esbuild) and fixed four correctness bugs in it, including a "Resolve All" that had silently only been covering open files rather than the whole workspace.

On the AI-agent side, v2.8.0 added an Agent Sessions view that detects running Claude Code, Cursor, and Windsurf processes by their working directories and cross-references them against your worktrees, plus four opt-in scheduled tasks (auto-resolve on conflict, nightly pull --rebase, release notes on tag push, AI commit-message batching). v3.2.0 fixed the terminal panel so that launching an agent from inside GitWand actually attaches a real interactive shell instead of a dead tab, and added a "New AI task" button that spins up an isolated git worktree and opens a Claude Code session in it in one click. The MCP catalog (v2.10.0) also turned Settings → MCP into a browser for the npm MCP ecosystem — hundreds of tagged packages, one-click install into Claude Desktop/Code, Cursor, or Windsurf configs.

Performance: fixing a CSP bug that had been quietly crippling IPC for months

v2.8.2 was a dedicated performance release: git status, the hottest IPC call in the app, moved from forking a git subprocess to running in-process via libgit2 (measurably faster, especially once fork-exec overhead disappears in the running app); twenty rarely-used panels and seventeen syntax-highlighter languages became lazy-loaded instead of parsed at launch; three independent polling timers were consolidated into one that pauses when the window loses focus; and every IPC call gained a default timeout, with longer presets for network operations and AI prompts.

v2.8.5 turned out to explain a lot of the sluggishness that preceded it: the Content Security Policy had never whitelisted Tauri 2's ipc://localhost protocol scheme, so every single IPC call was being silently rejected and falling back to Tauri's slow legacy postMessage path — the source of months of mysterious callback-id warnings in the console. The same CSP gap had also been blocking the Ollama detection probe and the Claude API endpoint. Fixing it, alongside a macOS launchd environment fix (GUI apps launched from Finder inherit essentially no shell environment) and a keychain ACL workaround for the GitHub CLI, resolved a cluster of "it works from the terminal but not from the app" bugs at once.

Where things stand

GitWand is at v3.2.0. Since the April article, the conflict engine gained tree-sitter structural merging, refactoring-aware resolution, and a validated LLM fallback; the forge support expanded from GitHub-only to GitHub, GitLab, Bitbucket, and Azure DevOps; the navigation model was rebuilt twice (Git Tree as primary view, then the floating dock); and a dedicated performance pass fixed both algorithmic hot paths and a CSP misconfiguration that had been quietly throttling every IPC call since Tauri 2 was adopted. If the April version didn't fit your workflow, most of what shipped since is aimed at exactly the gaps that would have caused that.