←back to thread

Show HN: I made a git rebase TUI editor

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

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 #
kccqzy ◴[14 Oct 24 15:00 UTC] No.41838175[source]▶
Yes after I recently discovered that even with squash & merge, the intermediate history isn't lost: they are not in the git history but they can still be viewed on GitHub.
replies(1): >>41838726 #
mkesper ◴[14 Oct 24 15:56 UTC] No.41838726[source]▶
But then git isn't your source of truth anymore. GitHub still references these commits until they're garbage collected one day.
replies(1): >>41838860 #
1. kccqzy ◴[14 Oct 24 16:07 UTC] No.41838860[source]▶
My understanding is that these commits don't get garbage collected ever. After all they still need to support `gh pr checkout` so they need to store them forever as part of the GitHub repo. Sure they won't be included in `git clone` but that's kind of the point.
replies(1): >>41839162 #
2. keybored ◴[14 Oct 24 16:37 UTC] No.41839162[source]▶
That’s correct. They will not ge GCd.

And yet that’s not usually what the problem is with having your canonical history “over there” in a proprietary webapp.

But if the history is easily available on those PR refs then I guess it is (under doubt) fine.

replies(1): >>41839458 #
3. skydhash ◴[14 Oct 24 17:02 UTC] No.41839458[source]▶
If you really care, you can use the API to extract the PR’s data in a local archive.
replies(1): >>41839493 #
4. keybored ◴[14 Oct 24 17:06 UTC] No.41839493{3}[source]▶
If I really care about the version control history? Yeah.

Alternatively I could stick with git(1) which does all of this stuff out of the box. Instead of having to learn a superflouous (for the job) API.

replies(1): >>41839581 #
5. skydhash ◴[14 Oct 24 17:13 UTC] No.41839581{4}[source]▶
I mean the PR data. The main advantage of a forge like Github are being web browseable, working great as a backup, and the PRs (and other stuff like artifacts storage and CI). All of these have alternatives and are optional. And the API is comprehensive enough to not feel locked in.
replies(1): >>41840358 #
6. keybored ◴[14 Oct 24 18:25 UTC] No.41840358{5}[source]▶
And I mean the “squashed” history. Because that’s what this subthread is about: the claim that it is available in GitHub so therefore it is fine.

I want the meaningful commits to be in the Git history. Because that’s a better place than the forge.

replies(1): >>41840513 #
7. skydhash ◴[14 Oct 24 18:40 UTC] No.41840513{6}[source]▶
When creating a squashed merge from the PR, it presents an interface for the commit message. You can put the information you want there.

It’s not a requirement. I wrote in another thread[0] why I like this methodology, but to each project its own.

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

replies(1): >>41840626 #
8. keybored ◴[14 Oct 24 18:52 UTC] No.41840626{7}[source]▶
I know that you can write information in the commit message.

That is not sufficient. Which I explained here.

https://news.ycombinator.com/item?id=41839438