←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.396s | 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. zabil ◴[14 Oct 24 14:55 UTC] No.41838122[source]▶
We do this. We deploy on commit to main and use the commit SHA for versioning. So squash merges makes it easier to know which commit caused a bug or bisect. This work well for our PR based workflows. If required the PR can be used as reference for un-squashed commits.
replies(1): >>41839191 #
2. keybored ◴[14 Oct 24 16:39 UTC] No.41839191[source]▶
If you deploy on merge (squash or regular) to main then having the commits squashed makes no difference with regards to finding out what was deployed.