←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: 0s | 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 #
dbalatero ◴[14 Oct 24 14:17 UTC] No.41837771[source]▶
Yep, IMO this is always the best of the 3 strategies.

The PR is the unit of work, people get too hung up on the PR's individual commits.

Worst: rebase and merge - you end up with your coworker's broken WIP commits all over master, and have a terrible git revert story

OK: merge commit - you can revert, but there is a less intuitive `-m 1` flag (IIRC?) you have to pass into revert, and IMO you rarely need the intermediate history.

Best: squash & merge - you get one single commit representing the unit of work merging in, git revert is dead easy

Also setting the commit message in main to the `{title} (#{prNum})\n\n{prDescription}` format preserves all the good context from your PR and lets you get back to it if you need.

replies(3): >>41838135 #>>41839005 #>>41839009 #
OskarS ◴[14 Oct 24 14:57 UTC] No.41838135[source]▶
I think "every PR should be a single commit when merged" is a bit too dogmatic. If the PR is logically split up into bits of work that conceptually separate and that compile/run independently, then it makes sense to have those as separate commits. You might argue that those should then be separate PRs, but that's going a bit too far, I think. You can still revert it, it's just have to revert the individual commits and squash the revert commits.

IMHO the guideline should be "clean up your branch and rebase it before merging. Usually that means a single commit, but it can be multiple if that makes more sense to <future person> reading the history".

replies(3): >>41839046 #>>41839061 #>>41839885 #
zomgwat ◴[14 Oct 24 17:44 UTC] No.41839885[source]▶
I don’t see it as too dogmatic. I see it as taking the ambiguity out of the decision whether to squash or not. Just always squash into master. There are plenty of options to make creating PRs more lightweight.

Another nice thing with squashing is that merges into master always look the same regardless of individual engineer workflows.

replies(1): >>41840653 #
keybored ◴[14 Oct 24 18:55 UTC] No.41840653[source]▶
Any dogmatic decision could be described as taking the ambiguity out of decisions.
replies(1): >>41844146 #
1. zomgwat ◴[15 Oct 24 01:51 UTC] No.41844146[source]▶
Sure. And that’s positive in the context of this thread.
replies(1): >>41849364 #
2. keybored ◴[15 Oct 24 15:04 UTC] No.41849364[source]▶
We’ve discussed the downsides of having such a policy in this subthread.

I want to have the choice to do a true merge or some other strategy. It’s a downside for me personally. Not having a choice doesn’t help me since it’s a meaningful choice in my book.

As a policy. I leave this decision for others. People who prefer can squash-merge all the time if they want to.