Show HN: I made a git rebase TUI editor

Original Article ↗ Hacker News Discussion ↗

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.