4 ms·

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 entirel

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.

NERD_ALERT 3y ago
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.
- srott 3y ago
  I was missing interactive rebase, as it is missing from libgit2 https://github.com/extrawurst/gitui/issues/32 https://github.com/extrawurst/gitui/issues/32
- piersolenski 3y ago
  I prefer the UI, especially with Vim key support, although LazyGit feels like it has slightly more features.
rrr_oh_man 3y ago
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 |
- fbdab103 3y ago
  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.
  - vrmiguel 3y ago
    I found the memory gains to be more enticing than the performance improvements
    - no_carrier 3y ago
      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?
zuhsetaqi 3y ago
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.

NERD_ALERT 3y ago

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.

srott 3y ago
I was missing interactive rebase, as it is missing from libgit2 https://github.com/extrawurst/gitui/issues/32 https://github.com/extrawurst/gitui/issues/32
piersolenski 3y ago
I prefer the UI, especially with Vim key support, although LazyGit feels like it has slightly more features.

rrr_oh_man 3y ago

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 |

fbdab103 3y ago
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.
- vrmiguel 3y ago
  I found the memory gains to be more enticing than the performance improvements
  - no_carrier 3y ago
    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?

zuhsetaqi 3y ago

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.