Rewrite Git history via drag-and-drop

A new macOS tool, Retcon, promises drag‑and‑drop rewriting of Git history, sparking debate over how much developers should edit commit logs versus preserving a full audit trail. Supporters value clean, well-structured histories for easier debugging, bisecting, and long-term maintenance, and see visual rebasing and deferred conflict resolution as genuine usability improvements over `git rebase -i`. Critics question paying a subscription for what they view as a polished GUI around existing Git features, noting alternatives like Sublime Merge, SmartGit, lazygit, jj, and GitButler that already streamline complex history editing in different ways.

Purpose and value of rewriting history

  • Many see value in rewriting only local or feature-branch history before merging: remove “oops/typo/WIP” commits, group related changes, and make each commit buildable and meaningful.
  • Clean history is viewed as critical for git bisect, git blame, and understanding why code changed; small, well-described commits help debugging years later.
  • Some use history rewriting to maintain internal forks of upstream projects, splitting local changes into well-isolated feature commits to ease future upstream updates.
  • Rewriting may be necessary in corporate setups when author name/email changes must be applied retroactively.

Skepticism and opposition

  • Others are uncomfortable with “rewriting history,” worrying it hides the real development path or weakens the audit trail.
  • Some prefer “messy but complete” logs, arguing that failed attempts and PR-fix commits can provide useful context or cultural insight.
  • There is disagreement on whether main should be perfectly clean vs. using merge commits and log filters while preserving all intermediate commits.

Retcon’s approach and technical aspects

  • Retcon is seen as a polished GUI wrapper around git rebase -i, with its main novelty being drag-and-drop reordering and rich undo/redo.
  • A key feature: when a move introduces conflicts, users can keep rearranging commits first and resolve conflicts later, all tracked in an in-memory “virtual history” before writing to Git.
  • Some want more: true DAG-based drag-and-drop rebasing, better conflict resolution, and powerful commit-splitting (down to line-level, via drag-and-drop).

Comparisons to existing tools

  • Alternatives mentioned: Sublime Merge, SmartGit, JetBrains IDEs, GitKraken, lazygit, jj/jujutsu (plus GUIs on top), GitButler, Fork, IntelliJ UI.
  • Several note that many of these already support interactive rebasing, drag-and-drop within limits, or advanced conflict handling; opinions differ on how smooth they are.

Pricing and adoption

  • Multiple commenters balk at a subscription (e.g., ~$10/month) for something used infrequently and seen as “just a nicer rebase UI,” preferring a modest one-time license.
  • The developer argues subscriptions help sustain long-term development; Retcon is also available via Homebrew.
  • Some doubt many will pay for a dedicated history-rewrite tool when free or existing paid tools already cover much of this workflow.