GitButler now supports first class conflicts, making rebasing less annoying

Original Article ↗ Hacker News Discussion ↗

GitButler’s new “first-class conflicts” feature prompts broader debate over how to manage Git history, especially whether rebasing for a clean, linear history is worth the extra complexity compared with simple merges. Commenters weigh the benefits for regression hunting, bisecting, and long‑running forks against risks like data loss from rebasing and force‑push, and point to tools such as `reflog` and `rerere` as safety nets. There is also interest and some skepticism around GitButler itself—its UX, nontraditional license, and platform support—given its ambition to improve everyday version-control workflows.

Rebasing vs Merging & Commit History

  • Large subthread debates whether rebasing is worth the effort compared to merging.
  • Pro‑rebase arguments:
    • Linear history is seen as easier to read, reason about, and bisect.
    • Rebasing commits individually avoids “giant patch bomb” merges and can make conflict resolution more incremental.
    • Clean, logically grouped commits aid review and long‑term forensics.
  • Pro‑merge arguments:
    • Merges preserve original history and branching structure, which some consider “objectively better” for understanding how changes evolved.
    • Rebased histories can create long chains of non‑compiling commits, making automated bisecting harder.
    • Squash merges and feature branches are said to be “good enough” for many teams, with less workflow overhead.
  • Several posters conclude the “right” choice depends on project scale, branching strategy, and how much value the team gets from fine‑grained history.

Rebasing Pain, Conflicts & Tools

  • Many note that long‑running branches and late rebases are the main source of pain; frequent small rebases help.
  • git rerere is highlighted as a built‑in mechanism that remembers conflict resolutions and greatly reduces repetitive conflict work; pitfalls include it also remembering incorrect resolutions.
  • Some prefer simple backup‑branch workflows over relying on reflog, while others emphasize reflog as the primary safety net.
  • Concerns raised that reflog and merge/rebase don’t protect uncommitted work; uncommitted changes can still be lost.

Git Bisect & CI Practices

  • Strong claims that linear histories make bisecting regressions dramatically faster; others argue bisect works fine with merges and that non‑compiling rebased commits are a bigger problem.
  • Disagreement over how realistic it is to require every individual commit (including rebased ones) to compile and pass tests, especially with long CI times.

Force‑Push Safety

  • One side views rebase + force‑push as inherently riskier and prefers “inherently safe” workflows.
  • Others argue data is rarely truly lost due to reflog and that force‑push (especially with --force-with-lease / similar) is safe and useful, particularly on isolated branches.

GitButler, Licensing & UX

  • Some express enthusiasm for GitButler’s design and conflict handling; others remain skeptical of new Git tools in general.
  • Noted that GitButler’s desktop app dropped Ubuntu 20.04 due to underlying toolkit support.
  • Its “functional source” / timed‑open licensing is called out as interesting but not unique.
  • One user criticizes the blog’s separation from the main product site and lack of clear navigation.