Show HN: I made a git rebase TUI editor

Original Article ↗ Hacker News Discussion ↗

A new Git rebase terminal UI was shared, but readers quickly discovered it doubles as a demo for a broader OCaml CLI/TUI framework, prompting confusion about its scope and how it compares to established tools like Lazygit, Magit, and git-interactive-rebase-tool. Commenters debate whether such specialized interfaces are necessary given Git’s ability to use any editor, and share mixed experiences with existing OCaml TUI frameworks. The conversation broadens into contrasting philosophies on Git workflows—particularly squash‑and‑merge policies versus preserving detailed commit history—and how these choices affect collaboration, code review, and long‑term project maintainability.

Project scope and initial confusion

  • Several readers expected a focused “git rebase TUI editor” but found a more general CLI/TUI framework repository.
  • Clarification: the repo hosts both a CLI framework and demo apps, including the rebase tool (“Newbase” section); some users missed this because anchor links didn’t scroll correctly.
  • A few people expressed reluctance to install a large, multi-purpose framework when they only wanted a single-purpose rebase tool.

Comparison to existing git TUIs

  • Multiple alternatives mentioned:
    • lazygit praised repeatedly as a powerful, general git TUI (rebase, logs, conflicts, etc.).
    • git-interactive-rebase-tool cited as a long-standing, solid rebase UI, and suggested integration via sequence.editor.
    • rebase-editor also mentioned as a mature solution.
  • Some users only want a good TUI log viewer; tools like tig, Emacs/magit, and Sublime Merge came up as partial fits.

OCaml / TUI framework discussion

  • The project appears to be a TUI/CLI framework in OCaml with demos, not just a git tool.
  • Prior TEA-style OCaml TUIs (e.g., teash) were reported as outdated or unreliable; some resorted to using Notty directly.
  • A code snippet with an explicit enum “increase/decrease” function prompted a question about a Haskell-like succ/pred for OCaml sum types; no clear resolution given.

AI, text UIs, and UX

  • One subthread notes that structured text plus an editor can replace many GUI widgets.
  • AI is discussed as a possible helper for enforcing formats and improving discoverability, but also criticized as mainly “bullshit-generation” used for rubber-ducking and autocomplete.

Git workflows and squash vs. merge

  • Long debate about team policies:
    • Pro–squash-merge: simpler PR history, single atomic commit per PR/task, easy reverts, cleaner main branch; PRs seen as the unit of work.
    • Skeptical view: squash-only policy is rigid, discards meaningful commit structure, pushes history into the forge (e.g., PRs) instead of git; rebasing and carefully crafted commits are preferred.
    • Some advocate stacked/dependent PRs with one commit each; others see this as overhead given current forge UX.
  • Disagreement on whether team-wide rules (always squash, no rebase) are necessary safeguards or unnecessary micromanagement.

Editors, configuration, and merge conflicts

  • Several comments note you can already choose any editor for interactive rebase via core.editor, GIT_EDITOR, or sequence.editor.
  • Some argue that a bit of vimtutor plus default interactive rebase is sufficient; others welcome specialized TUIs.
  • For merge conflicts, GUI tools like Meld are liked, but on remote/CLI-only setups, options are seen as lacking; lazygit and Emacs smerge are suggested as workable TUIs.