←back to thread

Show HN: I made a git rebase TUI editor

(github.com)
115 points NyuB | 2 comments | 13 Oct 24 20:03 UTC | HN request time: 0.433s | source

I use interactive rebase quite often, and particularly like the editor bundled with IntelliJ. But I do not always work with IntelliJ, and am not 'fluent' with Vim, so I tried to replicate roughly the same rebase experience within a TUI. I used a small TUI OCaml project i made last year.

The notable features are: - Move commits up and down, fixup, drop - Rename commits from the editor (without having to stop for a reword during the rebase run) - Visualize modified files along commits - 'Explode' a commit ,creating a commit for each modified file (a thing I found myself doing quite often)

Feedbacks (both on the tool and the code) and contributions welcome, hope it could fit other people needs too !

Show context
Olshansky ◴[14 Oct 24 14:11 UTC] No.41837708[source]▶
Is there anyone else that enforces a simple "just squash & merge everything from PRs into main" across the entire team?

I'm comfortable git fooing w/e is necessary, but ever since we adopted this, git related conversations went to almost zero. It's great.

replies(8): >>41837771 #>>41838122 #>>41838159 #>>41838175 #>>41838180 #>>41838920 #>>41840432 #>>41840852 #
1. Chromozon ◴[14 Oct 24 18:32 UTC] No.41840432[source]▶
My job follows this, and "rebase" isn't even in the vocabulary at work. It's just so simple- our developers spend zero time with git issues because there aren't any. The master branch history ends up being a sequence of pull requests that all have a corresponding code review. Everything stays nice and tidy.
replies(1): >>41840686 #
2. keybored ◴[14 Oct 24 18:59 UTC] No.41840686[source]▶
Rebase isn’t in our vocabulary either. Because those of us who use it just do it. And those that don’t, don’t.

And so there is no reason to interfere with anyone’s way of working.