Skip to content

GitView v0.1.13

Choose a tag to compare

@aldwinhermanudin aldwinhermanudin released this 30 Jul 04:45
· 50 commits to main since this release

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.