I struggled with Git, so I'm making a game to spare others the pain

Original Article ↗ Hacker News Discussion ↗

Alternatives to Git & staging semantics

  • Several commenters suggest alternatives: Mercurial, Jujutsu (jj), Fossil, Perforce, Subversion, Ark, Gitbutler.
  • Mercurial is praised as easier, with better branching/merging and “evolution” features; loss of big hosting (Google Code, Bitbucket) is seen as what killed it. Heptapod (GitLab fork with Mercurial) is cited as pleasant but niche.
  • Jujutsu is highlighted often: Mercurial-inspired, Rust-based, can operate on Git repos, and has first-class conflict handling and “megamerge” workflows. Some use it full‑time in Git-based companies.
  • Fossil gets strong praise: single binary, SQLite-backed, integrated web UI/wiki/bug tracker, simple CLI; some call it a tragedy that Git won instead.
  • Stage/index: some users consider staging essential for multi-task workflows; others argue it’s an unnecessary concept that complicates tools. Mercurial GUIs and jj workflows (interactive commit, squashing, splitting) are suggested as substitutes.

CLI vs GUI/TUI for Git

  • One camp sees source control as inherently visual: history is a tree/graph, so tools should be graphical-first with CLI as automation. They criticize Git’s CLI-first design and “visualizations as an afterthought.”
  • Another camp argues the CLI is ultimately clearer and more reliable once you have a mental model; GUIs can hide complexity and mislead. Many still use lightweight editor integrations (VS Code, JetBrains, Magit).
  • Merge conflict resolution is widely described as much easier in dedicated GUIs (JetBrains, P4Merge, VS Code, lazygit, Emacs ediff/SMerge); a minority insists CLI editing is fine and GUIs break down on complex merges.
  • Tools mentioned positively: Magit, SourceTree, Fork, Git Extensions, gitk, VS Code Git Graph (despite maintenance issues), lazygit, P4Merge, Perforce P4V. Some wish for better tree graphs and drag‑and‑drop rebasing.

Learning Git: mental models, minimalism, and pain

  • Many describe colleagues (even senior/staff) who only know “add/commit/push/pull” and Google anything else. Some see this as pragmatic; others as professional negligence.
  • Several argue that understanding Git’s underlying model (commits, refs, DAG, content-addressable store) is the real unlock; memorizing many commands is not.
  • Others counter that needing books and internals knowledge signals poor UX: Git exposes too much low-level complexity; as an “industrial tool” it should be boring and push‑button.
  • Opinions split between “use 3–4 commands and avoid the rabbit hole” and “learn your tools deeply; it pays off in debugging, history surgery, and collaboration.”

Games and visual teaching tools

  • The Git game in the article is seen as part of a broader trend: Oh My Git, LearnGitBranching, and other interactive/visual tutorials are frequently recommended and credited with major skill gains.
  • Some readers generalize this to other technical domains (e.g., EV/battery systems), arguing that short minigames can teach abstract concepts more effectively than text-heavy docs.