The git history command

Original Article ↗ Hacker News Discussion ↗

Git’s new experimental `history` command, which streamlines common interactive rebase tasks like fixups, splits and rewords, is prompting mixed reactions among developers. Some welcome the lower-friction way to rewrite and clean up commit history—especially for teaching juniors or maintaining bisectable, well-structured logs—while others argue that complex history editing is overused, prefer simple squash merges, or worry about UX pitfalls and conflicts. The thread broadens into a critique of Git’s usability, the value of curated vs. linear histories, and alternative tools such as jj, Magit, stgit, and semantic diff/merge helpers.

Role and usefulness of git history

  • New git history subcommands (fixup, split, reword) are seen as ergonomic wrappers around common git rebase -i workflows.
  • Some prefer sticking with interactive rebase for precise, “visual” control over commit ordering and editing.
  • git history fixup’s ability to automatically rewrite all descendant branches is appreciated, especially compared to rebase --update-refs, which behaves more narrowly.
  • A limitation noted: git history currently drops GPG signatures on rewritten commits, pushing some users back to rebase -i.

Conflict handling and UX pain

  • Strong disagreement over how “scary” rebases and conflicts really are.
    • One side: conflicts are a normal part of composing differing intents; fear reflects poor understanding of the code or git model.
    • Other side: even with good understanding, the UX around rebase states, “ours/theirs,” interactive tools, and mid-rebase edits feels brittle and mentally taxing.
  • Some argue Git treats code as plain text; others counter that line-based diffs are a pragmatic approximation and can be improved with tree-sitter–based tools.

Safety nets and recovery

  • Multiple reminders that git rebase --abort, git reflog, lightweight tags/branches, and git reset make experimentation safe.
  • Several people routinely create “before-rebase” branches or use reflog syntax (e.g., branch@{1}) to recover previous states.

Workflows: commit granularity, history rewriting, and squashing

  • Clear split:
    • “Curate history” camp: small, logical, bisectable commits; history used for debugging, regressions, and understanding intent. Rewriting unmerged history is encouraged; squashing is seen as throwing away value.
    • “Squash/append-only” camp: PRs as atomic units; internal commits are noisy “work logs” and should be squashed before merge. Emphasis on reviewer efficiency and business value over fine-grained history.
  • Debate over whether keeping failing-test commits, fixup commits, and revert chains is helpful (for TDD evidence and archeology) or harmful (breaks simple git bisect, complicates blame).

Tooling and alternatives

  • Several recommend higher-level tools to tame complexity:
    • GUIs like TortoiseGit, Magit, and lazygit.
    • Patch-stack tools like stgit.
    • Newer systems like jj, which many praise conceptually but find rough around Git interoperability.
  • Consensus that better UIs and stateful views significantly reduce the cognitive load of advanced Git operations.

Git learning curve and mental models

  • Some insist that understanding Git’s internal data model (via docs/books) makes everything click and that many complaints stem from not investing that time.
  • Others counter that widespread confusion indicates real UX problems, regardless of theoretical simplicity.