Show HN: I made a git rebase TUI editor

[NyuB]

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 !

[hu3]

I found this code interesting (not sarcasm) in demo/boiling.ml:

  let increase_level t =
    let level =
      match t.level with
      | No_Fire -> One_Fire
      | One_Fire -> Two_Fires
      | Two_Fires -> Three_Fires
      | Three_Fires -> Three_Fires
    in
    { t with level }
  ;;

  let decrease_level t =
    let level =
      match t.level with
      | No_Fire -> No_Fire
      | One_Fire -> No_Fire
      | Two_Fires -> One_Fire
      | Three_Fires -> Two_Fires
    in
    { t with level }
  ;;

[ivanjermakov]

Hmm, is there OCaml equivalent of Haskell's `succ`[1], which is inplemented for all sum types deriving `Enum`?

It would simplify these two functions to just `succ` and `pred`

[1]: https://hackage.haskell.org/package/base-4.20.0.1/docs/GHC-E...

[oniony]

Went to repository expecting a Git rebase editor and found a whole world of confusion.

Not sure what this project is now, it certainly does not seems to be a TUI focused on Git rebases.

[OJFord]

It seems to be a demo app for the framework described, your 'whole world of confusion' is the framework and other demo app(s):

https://github.com/NyuB/ocli?tab=readme-ov-file#newbase

[Bigpet]

I was confused at first too because I tabbed out and came back to it.

You need to scroll down to the `Newbase` Section. It's apparently both the repo for some kind of cli framework and for the rebase tool.

[nesk_]

I’ve been using rebase-editor for years and am pretty happy with it. Maybe it could be an inspiration for you?

Congrats for the release!

https://github.com/sjurba/rebase-editor

[DarmokJalad1701]

git-interactive-rebase-tool (https://github.com/MitMaro/git-interactive-rebase-tool) has been my go-to for many years now.

It is configured using `git config --global sequence.editor interactive-rebase-tool`. See if you are able to use that interface as well. That will make it easy to use without breaking existing workflows that use `git rebase -i`.

I will give it a try anyway.

[lostdog]

I wish there were a good TUI for handling merge conflicts. Vimdiff seems to be the closest, but doesn't have keyboard bindings for 3-way merges.

Nothing beats Meld for me, but if you're on a remote GUI-less machine, there aren't good options.

[arcanemachiner]

Lazygit works well for merge conflicts (and many other things):

https://github.com/jesseduffield/lazygit

(I am not actually sure what a three-way merge conflict is though TBH.)

[shawn_w]

emacs' smerge has always worked well for me.

[mro_name]

how is your tea different from https://opam.ocaml.org/packages/teash/?

[Degorath]

Sorry for the less-than-useful reply, but I tried out most of the TEA TUI frameworks in OCaml and none of them worked very well or well updated.

I do not recall what problem I had with that particular one, but I ended up just using raw Notty in the end.

[NyuB]

Thanks for the recommendations (which I will probably use rather than this hand-made version :P )

[the_duke]

I think all of this is available in lazygit as well, which seems to still be way too unknown, despite the 50k stars: https://github.com/jesseduffield/lazygit

[rkangel]

All I want is a good TUI git log viewer. I'm perfectly happy to do all the operations on the command line, but navigating the log works well interactively (e.g. start as --first-parent, with single line entries and then be able to selectively show branch commits, and patches for commits).

I end up with a log view and then copy and paste commit hashes to do different things. Or use Sublime Merge which is great, but doesn't work over SSH.

[amar-laksh]

Bloody love lazygit!

[chb]

No other TUI for git is comparable to it.

[jckahn]

lazygit is as necessary in my life as Vim. Absolutely incredible tool!

[shafyy]

Fucking love lazygit

[3D39739091]

Not trying to downplay your work, making cool tools is always cool, BUT:

1. You can also just configure Git to use whatever editor you'd like.

https://git-scm.com/docs/git-config#Documentation/git-config...

2. You don't need to be a Vim pro to interactive rebase effectively. Most of it will be `dd` to remove a line, `p` to paste a line, `j`/`k` to move up and down lines, and `cw` to change `pick` to `edit`, etc. Spend 15m with `vimtutor` (which is probably available on your system) and you'll never be afraid of vim again.

[serced]

TIL there is 'vimtutor'. I barely new the basics for quickly creating a file and inserting stuff. Will have a look if there is something to learn there, thanks for the pointer.

[samtheprogram]

Second this. Just change the EDITOR variable.

You’re getting downvoted (probably because of the mini Vim tutorial in #2) while the author of the post wrote a whole TUI because they didn’t know to change their EDITOR variable.

Learn your tools, people. This is the equivalent of a contractor taping rulers together because they didn’t realize their bag comes with a tape measure.

[syntaxing]

Nice work! Lazygit is a pretty popular too that does git stuff via a TUI (everything from rebasing to nuking your local)

[1] https://github.com/jesseduffield/lazygit

[NyuB]

Will definitely use this !

[kleiba]

Anyone using magit?

[amake]

It was the killer app that got me hooked on Emacs (which I now use as my IDE and daily driver for almost everything except web browsing).

Every time I see tools like this I think "ah, the normies are reimplementing Magit".

[koito17]

I use Magit for everything, never the Git CLI. Rebasing is very easy to do, and so is cherrypicking, looking at the ref log, etc.

Never bothered learning the Git CLI since it's always seemed cumbersome compared to Magit. That is the other major advantage to Magit, the UI is discoverable, there is always a subwindow displaying all available commands and most of the commonly used flags. (Less commonly used flags can be displayed by adjusting the transient level.)

[_ix]

I do. It works so well I've almost taken it for granted.

[ckolkey]

Missed it so much in vim I started maintaining the neovim clone.

[SoftTalker]

Yes. Only tool I've found that makes git usable.

[umanwizard]

I use it, it’s great.

[Olshansky]

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.

[AnthOlei]

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 :)

[dbalatero]

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.

[Chromozon]

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.

[zabil]

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.

[Degorath]

But that way you make stacked diffs/changes/PRs really hard, so is it really worth it?

I firmly believe GitHub makes reviewing individual commits in a PR so painful that I'd rather not do that.

[keybored]

> Is there anyone else that enforces a simple "just squash & merge everything from PRs into main" across the entire team?

No. This kind of policy has plenty of downsides[1] and the upsides are relatively minor.

[1] https://news.ycombinator.com/item?id=41653892

[kccqzy]

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.

[bruwozniak]

I got fairly good mileage with https://github.com/MitMaro/git-interactive-rebase-tool/ which has similar goal

[morgansolis]

What is the main purpose of the ocli project on GitHub, and how can I use it in my command-line applications?

[xuhu]

Watching the screencast I realize how often text and an editor are a replacement for lists, treeviews, tabs, scrollbars etc.

Maybe AI is the answer for enforcing the format and for discoverability since it provides GUI-like hand holding without the hassle of actually writing GUI code.

[chx]

AI is never the answer. Unless ...

https://hachyderm.io/@inthehands/112006855076082650

> You might be surprised to learn that I actually think LLMs have the potential to be not only fun but genuinely useful. “Show me some bullshit that would be typical in this context” can be a genuinely helpful question to have answered, in code and in natural language — for brainstorming, for seeing common conventions in an unfamiliar context, for having something crappy to react to.

> Alas, that does not remotely resemble how people are pitching this technology.