Grace Version Control System

Original Article ↗ Hacker News Discussion ↗

Offline vs. always-online design

  • Many see the lack of offline operation as a major flaw. Examples: working on planes, hotel Wi‑Fi outages, power/network instability, air‑gapped environments. Git’s local commits are seen as a key advantage.
  • The project’s author argues most modern workflows already require connectivity (cloud CI, cloud infra, Git hosting) and that by the late 2020s near‑constant internet can be assumed; offline needs can continue to use Git.
  • Some reject this, valuing local repos as resilience against host failures and as a deliberate design principle (“complexity bad; centralized VCS is a step backward”).

Automatic upload on save, monitoring, and privacy

  • Auto‑upload on every save via a background watcher triggers strong pushback:
    • Fear of leaking secrets, temporary hacks, profanity, or experimental code.
    • Concern about huge repos due to large temporary files and potential “repo‑bomb” attacks.
    • Worry about surveillance/metrics (“every save timestamp visible to the boss”) and “ghost in the machine” auto‑rebases breaking flow or tests mid-edit.
  • Proponents like the “ambient” experience, likening it to OneDrive/Dropbox/Box and using VCS as continuous undo.
  • The author stresses that:
    • watch is optional.
    • Saves/checkpoints are ephemeral, auto‑deleted after a configurable time.
    • Deleting specific versions is a first-class operation, combined with secret-scanning.

Centralization, branches vs forks

  • Centralized, cloud‑native server on Kubernetes is unattractive for those who want local, simple, self‑contained repos.
  • Replacing forks with “personal branches” on the main repo is widely criticized:
    • Maintainers see “everyone branches on upstream” as unmanageable.
    • Forks are also used for long‑lived private divergence, not just contribution.
  • The author frames forks as a hoster workaround; Grace aims for branch‑level permissions and personal branches to cover open-source workflows.

UX, concepts, and Git comparison

  • Some like:
    • Separating “checkpoint” (WIP), “commit” (candidate), and “promotion” (to parent branch) instead of Git’s single “commit.”
    • Auto‑rebasing child branches on parent updates and removing explicit stashing.
    • Better handling of large repos and binaries, event‑sourced history, and future AI‑assisted conflict resolution.
  • Critics:
    • Find the README heavy on marketing/buzzwords (“cloud-native”, “AI”) and light on clear core concepts: repository model, storage, IDs, concurrency, merge semantics.
    • Fear Grace may be “easier” at the surface but more conceptually complex than Git’s blobs/trees/commits/refs.
    • Object to AI in VCS, preferring “dumb/simple” tools.

Large files and non‑code assets

  • Game/Perforce users and others with big binary assets are a key target; there’s side discussion of VCSs that diff binaries semantically (images, 3D scenes, sound).
  • Some see this as an important differentiator; others say Git + existing tooling (LFS, diff viewers) is usually enough.

Tooling, platform, and adoption

  • Native cross‑platform GUI (Avalonia) and .NET/F# implementation get positive notes; some still prefer web or TUI.
  • Multiple commenters doubt adoption prospects: requires cloud infra, seems enterprise‑oriented, and fights Git’s massive network effects.
  • The author positions Grace as an open-source, cloud‑hoster‑adopted successor to Git, not a standalone “GitHub competitor.”