The Real Problems w/ Git

Git sparks a bigger fight than “merge vs rebase.” Across the standup, the central complaint is that version control forces developers to think about internal mechanics—conflicts, history shape, branching rules, and command-line workflows—when most people just want their work saved and shared reliably. One participant’s ideal system is almost hands-off: type a single “done,” have changes automatically available across machines, and only surface conflicts as a clear, later choice instead of interrupting day-to-day coding.

That frustration shows up repeatedly in how people describe failure modes. A “botched rebase” can happen when conflicts derail attention mid-rebase, leading someone to abort and recover by recloning or restoring from a saved state. But the deeper issue isn’t the specific command; it’s the cognitive tax. The discussion argues that Git’s model—where history is arranged through pushes, pulls, merges, rebases, and squashes—turns source control into an ongoing mental project. Even when Git works, the workflow can feel like programmers are “facilitating source code control” rather than writing software.

The standup also contrasts two philosophies for representing change history. One side prefers squashing: compress many intermediate commits into a smaller, coherent change set that should represent a working feature, making later debugging and archaeology more straightforward. The other side defends rebasing as a way to test a feature branch on top of the latest known changes, avoiding the false comfort of merging something that looked good earlier but becomes untrustworthy once new commits land. The debate extends to whether commit granularity matters: some want to preserve the “forensic evidence” of how a change evolved, including imperfect commit messages that encode context like “trying something” or “uncharted territory,” while others treat that detail as noise that distracts from the actual deliverable.

A parallel thread targets GitHub-style workflows and tooling ergonomics. The criticism isn’t only Git’s underlying DAG model; it’s also the user experience—arcane commands, confusing error states, and interfaces that don’t make diffs and review frictionless. The group repeatedly returns to a “Steve Jobs of source control” idea: sane defaults, a small set of commands that cover most needs, and prompts that guide humans only when action is truly required.

Finally, the conversation lands on a pragmatic conclusion: version control is not solved because humans and organizations differ. Large teams need stricter coordination, while small teams can tolerate “let it ride” approaches that preserve multiple versions until someone chooses to reconcile them. Hooks and automation are discussed as potential guardrails, but there’s skepticism that they should block commits broadly—especially when the real goal is preventing shared-area problems like accidental secrets. The episode ends with the view that Git is “the worst system except for all the others,” not because it’s perfect, but because no widely adopted alternative matches its combination of flexibility, tooling, and proven workflows—despite the clear desire for something more transparent and less burdensome.