Hacker News Reader

Comment by jonwest | Hacker News Reader

I see that lazygit is listed as inspiration for this project. As a lazygit user myself I'd be curious as to what was lacking from lazygit to warrant an entirely new project, as I've found it to be incredibly useful.

View on HN

I cannot judge whether the methodology makes sense, but the numbers seem quite impressive for my manager brain:

> Readme.md

  For a RustBerlin meetup presentation I compared lazygit, tig and gitui by
  parsing the entire Linux git repository (which contains over 900k commits):


  |         | Time       | Memory (GB) | Binary (MB) | Freezes   | Crashes   |
  | ------- | ---------- | ----------- | ----------- | --------- | --------- |
  | gitui   | 24 s       | 0.17        | 1.4         | No        | No        |
  | lazygit | 57 s       | 2.6         | 16          | Yes       | Sometimes |
  | tig     | 4 m 20 s   | 1.3         | 0.6         | Sometimes | No        |

On the other hand, I do not work on a repository nearly the size of Linux. If you evaluate performance on a more modest project, is there a meaningfully human speed difference?

I will always take faster tools, but sometimes things are good enough.

I found the memory gains to be more enticing than the performance improvements

Those memory figures relate to parsing the linux kernel repo, so the parent's question still remains, if it matters to the rest of us?

I’ve been a daily lazygit user for years and tried this out a few months ago. Seems like a case of rewriting a near perfect tool in Rust just for the sake of doing it. From what I remember this project didn’t have any features that aren’t present in lazygit but was lacking some that are.

I was missing interactive rebase, as it is missing from libgit2

https://github.com/extrawurst/gitui/issues/32

I prefer the UI, especially with Vim key support, although LazyGit feels like it has slightly more features.

He says it in the README:

> 2. Motivation

> I do most of my git work in a terminal but I frequently found myself using git GUIs for some use-cases like: index, commit, diff, stash, blame and log.

> Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable.

Reply on news.ycombinator.com