How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
Neat project, but the README would benefit from a human author. I can tell what you prompted by the way the README is worded. It should tell me more about what this project solves. I don't care that it uses idiomatic zig. Why should I use this instead of lazygit?
This is probably the most valuable feedback received so far. I'll make sure to draft a new README file following what you have suggested. The current version was partially written with the help of AI as English is not my primary language but I recognize that I should put more emphasis on what this project solves. I've put a few points in a separate file called ENHANCEMENTS_OVER_LAZYGIT.md but I will probably review and merge it into the primary README file.
Thanks!
Yes, from the README, it's not clear why the author would maintain a project with main features being saving 10Mb of ram&storage and 10ms startup time... followed by a wall of hard-to-read AI-generated text.
Disagree that "if the wall of text is the worst critique, the code's fine." Docs quality and code quality aren't independent. A maintainer who can't explain why a tool exists usually hasn't thought hard about the tradeoffs either. That's the actual signal people are reacting to.
To restate my initial point, I don't think the speed is important for tools like `lazygit`. Even on the huge company-wide monorepos it's not a problem, as there are other ways to handle it. For now, you're selling Ziggity to the Zig bros.
> But if "a wall of text" is the strongest critique here
Well, it is a blocker, since you haven't convinced me to try it. The only feature I find useful is the text selection, and to find it I had to dig through the "wall of text".
You have 10s to tell me what my pain point is and how you solve it, before I move on. I understand you're proud of the speed gains. But as a potential (typical) customer, I'm telling you it's not the problem I have.
If this is idiomatic zig, functions must be expensive because it fails horribly in the DRY departement. Also, papering over exceptions everywhere by... catching and not handling exceptions. What could possibly go wrong?
This is huge. I've always wanted to use Git in the terminal but never been happy with the underlying language that other TUIs were written in. Now that I know that I'm using developer-managed memory I can be much more comfortable and confident changing between branches, pushing, and pulling, and even merging code. Thanks Simone!
Happy to receive feedback and suggestions if you have any.
I've used Lazygit for several years, and it's an amazing project, but I'm much faster and productive with Ziggity now: you'll never leave the TUI, and the text is selectable with the mouse.
I've been using tig, written in C, for ages now, never once crashed. And I'm all for safe languages, but a git TUI isn't really as critical as you imply - if I interpreted the sarcasm correctly.
it is necessary to discern whether the person actually believes it or not. you may understand it but internet is accessible by a lot of idiots. at least one of them is inclined to take the words at face value
Been writing Zig for about a year now and this thread's a good example of why /s exists online: tone doesn't survive text the way it does in person. Ran into the same thing pitching Zig's error handling at work, half the room thought I was joking.
Rewrite ships, works fine for six months. Then one contributor "cleans up" the config parser and prod breaks in a way that takes three days to bisect. Same story, new language.
Very cool, but if I'm prompting / looping an AI agent as my main development process, what is the use case here? I feel the biggest help would be to make Reviewing PRs from the terminal easier, I care less about commit logs and status.
you can see the diff before you merge it. my main use case for lg is looking at diff and staging logical parts then committing with another tool or manually.
So many wrong assumptions in a single message.
Lazygit is a fantastic project, I've been using it for several years, but there were so many things I wanted to improve/change, that eventually I decided to create my own project. Go is not a language I wanted to explore, while I had this interest in giving Zig a try, so eventually I picked it and was blown away by how fast it can be.
There's a file called ENHANCEMENTS_OVER_LAZYGIT.md (https://github.com/simoarpe/ziggity/blob/main/docs/ENHANCEME...) but I'll soon merge it into the main README.
At my daily job, I handle huge git projects, and use Ziggity daily now, and I'm much more productive.
I can name a few improvements over Lazygit in random orders:
- Text selection with automatic copy, it works super smoothly and it's useful when you need to quickly copy a commit hash, a portion of code, a diff, or a branch name.
- Force-push with lease, it's something that should be always used when force pushing. If you work in a large codebase it should always be your first attempt after a rebase, and that's how Ziggity works. It will ask to fallback to normal force-push if it didn't work, but you'll remain in control.
- Git actions are async without leaving the TUI: this is in my opinion the biggest improvement over Lazygit, and it makes me much more productive, Lazygit was continuously switching to prompt and asking to press to return back to the TUI. There are also good reasons for this but as a general philosophy I wanted something different, and more optimized.
- I've implemented the 50/72 rule (https://dev.to/noelworden/improving-your-commit-message-with...) for the commits and I can finally prepare good commits, where I highlight when a title is too long and there's a shadow for the linewrap. They are both configurable so I'm not forcing this option.
- I have also implemented the correct behavior a couple of other features that are currently broken on Lazygit, the most serious one for example is that switching branch by name is completely broken and you'll end up in commit in a detached state (try yourself if you don't believe me).
So to answer your question: You should not switch to Ziggity if you are fine with Lazygit. But if you are a proficient Git user, handle largit Git projects, and you have used Lazygit for a while and noticed a few things were "suboptimal"; then you should give Ziggity a try.
Same take we had in the 90s about editors — vi vs emacs vs whatever, nobody cared what BASIC or C the thing was written in. Lazygit already won that fight, this needs a reason to exist beyond "zig."
Serious suggestion, as we’re going to get many such submissions in the future.
Can we have an honor code policy of no LLM agents used in development if you want to present on Hacker News.
The way I think of it is if we have a forum for painters and then someone just keeps sharing GenAI paintings that he did not actually paint. It’s ridiculous, I want to look at stuff humans painted, not AI.
Yes software does have use, and LLM companies have managed to make it so that anyone can build useful software for themselves if they want. So what’s left, is software as an art to appreciate, and I can’t appreciate AI generated art or software whether it is “good”, “functional”, “idiomatic”, “elegant” whatever. We still watch humans play chess, not computers play against each other though sometimes they can be interesting.
I’m not a “Luddite”, I’m unhappy with the way American AI companies have gone about this, if they released open weights it would be better.
But AI fundamentally changes the meaning of developing software, the way a compiler doesn’t. There’s no building software once you’re using LLM, just as there’s no playing chess when you have a chess engine to help you. And maybe AI code will not look like slop in the future, doesn’t matter, I still don’t really care if an AI built it.
I’m such a CLANKER hater now, I want to know if this was written by agents or not. If written by agents, I don’t want anything to do with it. I only want human written software, even LLM autocomplete seems a bridge too far.
I've used Lazygit daily for almost four years. It's a fantastic project, and I suggest donating to Jesse as he did a great job.
In my daily job a heavily use Git and a few things bothered me, so I decided to create my own project. Go is not a language I wanted to explore, while I had this interest in giving Zig a try, so eventually I picked it and was blown away by how fast it can be. There's a file called ENHANCEMENTS_OVER_LAZYGIT.md (https://github.com/simoarpe/ziggity/blob/main/docs/ENHANCEME...) but I'll soon merge it into the main README. At my daily job, I handle huge git projects, and use Ziggity daily now, and I'm much more productive.
I can name a few improvements over Lazygit in random orders:
- Text selection with automatic copy, it works super smoothly and it's useful when you need to quickly copy a commit hash, a portion of code, a diff, or a branch name.
- Force-push with lease, it's something that should be always used when force pushing. If you work in a large codebase it should always be your first attempt after a rebase, and that's how Ziggity works. It will ask to fallback to normal force-push if it didn't work, but you'll remain in control.
- Git actions are async without leaving the TUI: this is in my opinion the biggest improvement over Lazygit, and it makes me much more productive, Lazygit was continuously switching to prompt and asking to press to return back to the TUI. There are also good reasons for this but as a general philosophy I wanted something different, and more optimized.
- I've implemented the 50/72 rule (https://dev.to/noelworden/improving-your-commit-message-with...) for the commits and I can finally prepare good commits, where I highlight when a title is too long and there's a shadow for the linewrap. They are both configurable so I'm not forcing this option.
- I have also implemented the correct behavior a couple of other features that are currently broken on Lazygit, the most serious one for example is that switching branch by name is completely broken and you'll end up in commit in a detached state (try yourself if you don't believe me).
If you decide to give Ziggity a try, I'm happy to receive feedback
Hi HN, I've been building Ziggity, a keyboard-driven terminal UI for Git.
It's inspired by lazygit (which I used daily), but written from scratch in Zig rather than being a port.
Why another one? Two reasons, honestly. There were a few areas of lazygit I wanted to improve on for my own workflow, and I wanted a real project to build in Zig, which is genuinely powerful and fast, and a joy once it clicks. It compiles to a single small static binary with explicit memory ownership and no libgit2, it just shells out to the `git` you already have. The UI is built on libvaxis. And I let myself add a bit of sugar along the way, because a tool you stare at all day might as well be pleasant.
A few things that are a bit different from lazygit:
- A divergence view + status-coloured commit hashes so ahead/behind commits stand out at a glance
- Independent drill-downs in the Branches/Commits panels (deliberate, not a port artifact)
- Line level staging, interactive rebase, custom patch building, bisect, arbitrary-ref diffing
It's honest about its stage: v0.3.0, macOS/Linux/Windows builds, MIT. The Windows build compiles and libvaxis supports it, but I haven't smoke-tested it on real hardware yet. There's an about screen with a spinning ASCII donut, because why not.
Install: `brew install simoarpe/ziggity/ziggity`, or grab a static binary
from the releases page.
I'd genuinely appreciate feedback, especially on the UX and on the Zig code if you're into that. It's a spare time project, so bug reports and "this feels wrong" notes are welcome.
It's probably because of HN's anti-LLM filter. I don't know if submitters use LLMs to touch up their descriptions or if these descriptions often use LLM-like phrasing.
Switched our team off lazygit to a Rust one last year mostly for the memory footprint on huge repos, so curious how Zig's manual allocation handles diffing massive files. That was the one place lazygit choked for us, staging anything over a few hundred MB.
Rewrite in Zig, Rust, whatever — doesn't matter if nobody's running it in prod six months from now. We tried three different git TUIs at our last shop, all died from maintainer burnout. Ship it, but budget for that.
