←back to thread

Show HN: I made a git rebase TUI editor

(github.com)
115 points NyuB | 3 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 #
AnthOlei ◴[14 Oct 24 15:00 UTC] No.41838180[source]▶
I’ve recently spent time truly learning git, and I’m realizing how much better it is to take care of your commits in a PR even if you squash to main.

My reviewers love when I write “review commit by commit” in the PR description. Then each individual commit has its own reasoning, and you can mentally switch into reviewing if that commit does it’s one thing it’s supposed to do correctly. I will accept the argument that each commit should be its own PR though :)

replies(2): >>41838217 #>>41838964 #
keybored ◴[14 Oct 24 16:16 UTC] No.41838964[source]▶
This is so puzzling to me. It’s like people[1] get so stuck in the GitHub PR framework/mindset that they then, after realizing that GitHub PRs suck for reviewing individual commits, discard commits as the reviewable unit and then shoehorn one-commit-per-PR as a replacement.

The PR is just the best GitHub had to offer. There are other approaches to code review.

[1] Here we are generalizing.

replies(1): >>41839413 #
skydhash ◴[14 Oct 24 16:59 UTC] No.41839413[source]▶
I treat PRs like the email workflow. You send a diff my way for a particular changes, I either accept it or reject it. Or I suggest modifications. Recursively. It’s the whole patch I’m interested in, not the implementation history (I’m not your tutor). Once approved, I make a commit in main for this diff.
replies(1): >>41840461 #
keybored ◴[14 Oct 24 18:35 UTC] No.41840461[source]▶
The classic email workflow is either one patch or a patch series. Where each patch becomes a commit. And each patch can be reviewed in isolation (like a commit).

It is not anemic like the squash workflow.

replies(1): >>41840625 #
skydhash ◴[14 Oct 24 18:52 UTC] No.41840625[source]▶
There’s nothing stopping anyone from creating a PR series. My reasoning for the squash workflow is described here[0]. I just equate a PR to a patch. And it becomes a commit in the main branch. I don’t really care about the commits in the PR, just like no one cares about the commits that produced the patch in the email workflow.

[0]: https://news.ycombinator.com/item?id=41839282

replies(1): >>41840722 #
1. keybored ◴[14 Oct 24 19:02 UTC] No.41840722[source]▶
> I don’t really care about the commits in the PR, just like no one cares about the commits that produced the patch in the email workflow.

They do care. They go through the trouble of reviewing it so that the resulting commit[1] that lands in the upstream repository is good.

[1] Presumably you don’t mean “they don’t care about the commit that produced the patch”… since the patch is just a transport format for the commit.

replies(1): >>41840966 #
2. skydhash ◴[14 Oct 24 19:26 UTC] No.41840966[source]▶
> Presumably you don’t mean “they don’t care about the commit that produced the patch”… since the patch is just a transport format for the commit.

Commits. Not everyone will care to clean up their local history just to produce a single patch. You can git diff it out.

EDIT:

I was using "patch" for diff so scratch the above comment. Even then, when using a forge, I'd rather use squash unless everyone clean up their commit history when producing a PR.

replies(1): >>41849377 #
3. keybored ◴[15 Oct 24 15:05 UTC] No.41849377[source]▶
This must mean that you don’t use PRs like the email workflow since nothing of what you’ve described looks like any email workflow that I’ve seen.