GitView v0.1.13
Bridge-only release, and an important one if you run the bridge on a machine with large repositories.
⚠️ The .deb filename has changed
There is no longer a single gitview-bridge_<version>_all.deb. The package is now architecture-specific:
gitview-bridge_0.1.13_amd64.deb ← most machines
gitview-bridge_0.1.13_arm64.deb ← Raspberry Pi, Apple-silicon VMs, ARM servers
Anything scripted against the old filename needs updating. Installing the wrong one now fails at
install time, which is the improvement — before, an architecture mismatch could only fail later, at
runtime.
Nothing else about installing or upgrading changes, and no re-pairing is needed.
The bridge was consuming every file watch on the machine
On a host with sizeable repositories the bridge would quietly take every inotify watch the kernel
allows — on the dev box, 119,573 of 119,664. Two things followed, both silent:
- The bridge stopped noticing file changes. It kept serving, kept answering health checks, and simply
never pushed another update. Nothing in the log said so. - Everything else on the machine broke too. Once the budget is exhausted, any program that wants a
file watcher fails — editors, build tools, test runners.
The cause was watching every file, not every directory. A directory watch already reports changes to the
files inside it, so the per-file watches bought nothing and cost everything. The bridge now uses the same
directory-level watcher VS Code does, and skips whatever the repository's own .gitignore excludes —
asked of git directly rather than guessed at, so build output and vendored dependencies are never walked.
Measured on the same machine and repositories: 119,573 watches → 8,458. On a second host with a
237,000-path repository, 14,007 — a repository that alone would previously have wanted twice the
kernel's entire limit.
If you have ever seen "unable to watch for file changes" from an editor on a machine running the bridge,
this was very likely why.
Also
- A repository that cannot be watched now says so in the log instead of failing silently — it was
indistinguishable from one whose initial scan was still running. - Removing a workspace while its initial scan was still in progress could leave a watcher behind that
nothing could release. Fixed, with a test that fails without the fix.
Artifacts
Bridge 0.1.13 (amd64 and arm64), app 0.1.12 — unchanged this cycle and included so the tag
carries the complete pair. Verify the APK signature against the cert SHA-256 in the README before
installing.