Why I Still Hate Git and What a Perfect VCS Should Look Like

Why Git feels hard to use

Typical daily Git workflow involves creating branches, pushing to a remote, opening pull requests, and letting CI/CD run. Many commands ( git reset, git revert, git checkout, git clone, git pull, git fetch, git cherry-pick) have subtle differences that clash with a developer’s mental model. Common friction points include:

Needing to git stash before switching branches.

Finding the last commit that touched a file with git rev-list -n 1 HEAD -- <filename>.

Undoing a mistaken commit using git reset --hard HEAD~1.

These operations are powerful but feel over‑engineered for the majority of developers.

Desired features of an ideal VCS

Server‑centric model : Reduce the need for constant remote access and decentralisation.

On‑demand server operations : Search and retrieve only the files required for a task instead of cloning the whole repository.

Sparse checkout : Download only the subset of files actually needed.

First‑class pull‑request support : Integrate PR validation and dry‑run checks directly into the CLI.

Simplified cross‑version dependencies : Clear handling of submodules and subtrees.

Built‑in visualisation : CLI‑driven UI that shows repository state without external GUI tools.

Centralised commit‑message and policy enforcement : Validate commit messages and other rules at clone time.

Read‑replica architecture : Allow CI/CD to target a read‑only replica while the primary VCS remains available.

Subversion (SVN) – a simpler alternative

SVN uses a centralised model where each commit creates a new global revision number. The command set is straightforward (add, delete, copy, move, mkdir, status, diff, update, commit, log, revert, etc.). File states are expressed as four categories (local unchanged, local modified, remote newer, both modified). A typical SVN workflow:

Ensure network connectivity.

Run svn update to bring the working copy to the latest revision.

Make changes using svn copy or svn move (instead of OS moves).

Verify changes with svn diff.

Resolve conflicts if any, then run svn update again.

Commit the final changes with svn commit.

SVN’s simplicity avoids many Git pitfalls, but its branching model is limited and its UI is dated.

Sapling – Meta’s modern VCS

Sapling mirrors many Git commands ( sl clone, sl status, sl commit) while adding a “stack” of commits and a “smartlog” view. Example usage:

❯ sl st</code><code>? Dockerfile</code><code>? all_functions.py</code><code>sl add .</code><code>adding Dockerfile</code><code>❯ sl</code><code>@ 5a23c603a 4 seconds ago mathew.duggan

Navigate the stack with sl prev 1 and create pull requests via sl pr. Sapling’s server‑side component is **Mononoke** and its filesystem layer is **EdenFS**. Relevant repository URLs:

https://github.com/facebook/sapling/blob/main/eden/mononoke/README.md

https://github.com/facebook/sapling/blob/main/eden/fs/docs/Overview.md

Key innovations include on‑demand file fetching, file‑system monitoring (watchman), sparse checkout, selective pull, incremental work‑tree updates, and fast commit‑graph algorithms. Sapling also provides undo‑oriented commands such as uncommit, unamend, unhide, and undo. However, it still relies on GitHub for PR handling and requires Meta’s ecosystem for full functionality.

Scalar – Microsoft’s large‑repo helper

Scalar is a Git‑based tool that automates modern Git options for massive monorepos. Its main features are:

Built‑in file‑system monitor (FSMonitor) to avoid scanning the entire tree on git status.

Multi‑pack handling and commit‑graph optimisation for faster history traversal.

Sparse‑checkout and partial clone support to limit the local checkout to needed files.

Integration with the gh CLI for streamlined PR workflows.

Scalar’s purpose is to make large codebases performant without changing Git’s core architecture. Documentation can be found at:

https://github.com/microsoft/scalar

Conclusion

Git remains the dominant VCS but its decentralised design and command complexity hinder everyday usability for many developers. SVN offers a simpler, centralised workflow but lacks modern branching and UI features. Sapling introduces promising concepts such as commit stacks, on‑demand fetching, and robust undo commands, yet it is tightly coupled to Meta’s infrastructure. Scalar improves large‑repo performance by configuring Git optimally but does not fundamentally alter Git’s model. The search for a VCS that balances decentralisation, usability, and scalability continues.