Rendered at 21:29:55 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
greggroth 1 days ago [-]
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?
TheSorcerer 11 hours ago [-]
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!
arjie 1 days ago [-]
In general, for most projects like this the README is the product. You usually have better results using it and the code as a starter prompt for your own software if you feel the need. I wouldn’t use this kind of thing directly from upstream.
tosti 1 days ago [-]
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?
blueaquilae 24 hours ago [-]
You have no idea don't you? it's like telling Ghostty failed because you don't understand how try/catch was a mistake in software conception.
dwattttt 20 hours ago [-]
Why are there exceptions in the first place then? If that's what you want, write ON ERROR RESUME NEXT and be honest about it.
JacobAsmuth 1 days ago [-]
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!
TheSorcerer 11 hours ago [-]
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.
ind-igo 18 hours ago [-]
I'm amazed at the comments on this.
blueaquilae 24 hours ago [-]
This is just a copy of LazyGit the original and long player git in tui
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.
whimsicalism 1 days ago [-]
you dropped your /s
petepete 14 hours ago [-]
/s isn't necessary, sarcasm shouldn't be signposted.
rk06 11 hours ago [-]
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
sigmonsays 1 days ago [-]
prolly authored it in a tui and it crashed, since it wasn't written in rust
dd_xplore 1 days ago [-]
I wonder when is the 900,000 lines single commit coming for Rust rewrite
onlyrealcuzzo 1 days ago [-]
I'm working on porting the Rust compiler to VB.NET, so I can run it inside Excel spreadsheets.
And so it's "actually memory safe".
/sarcasm in case not obvious.
ubercore 1 days ago [-]
I really want someone to do this now.
patmorgan23 18 hours ago [-]
Port it to PowerPoint!
TheSorcerer 11 hours ago [-]
Never! (Pinky finger)
IshKebab 1 days ago [-]
It's written by Claude already so it probably wouldn't make any difference I guess?
v3ss0n 1 days ago [-]
You beat me to it
pelasaco 1 days ago [-]
dont worry, soon or late it will show up in HN..
sashank_1509 3 hours ago [-]
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.
kvisner 1 days ago [-]
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.
1 days ago [-]
temphaaa 14 hours ago [-]
just use lazygit, i don't see why i would care if it's zig/go/rust or whatever compiled language
I know what these words mean, but if I didn't this would be a whole lot of nonsense.
arikrahman 1 days ago [-]
Maybe can emphasize yourself and call it LazyZig or something with the lazy moniker.
v3ss0n 1 days ago [-]
Lazy in a way that it was been vibe coded
PrimalPower 23 hours ago [-]
i've always found magit better than any opinionated git terminal UI. Including LazyGit.
With Claude, i find myself reaching for Magit even less.
mayhemducks 23 hours ago [-]
If Quagmire were in charge of naming things.
alimbada 1 days ago [-]
I like the Zig+Git+TTY portmanteau.
sashank_1509 1 days ago [-]
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.
jllyhill 24 hours ago [-]
You can just scroll down to the contributors section to see that it was indeed written by Claude
hoppp 1 days ago [-]
Understandable
Yes, smells like vibe code. Haven't looked inside but can already tell
ursuscamp 1 days ago [-]
You're in for a great deal of pain in the coming years.
whimsicalism 1 days ago [-]
some of you all need to take a break from politics, it is clearly not doing you good and easy to get swept up into group mania imo.
rvz 1 days ago [-]
So you guarantee that you yourself will never use AI or agents in any capacity?
Is that the principled position you want stand on in 2026 and beyond?
sashank_1509 1 days ago [-]
Yes I won’t use LLM autocomplete or agents for any personal projects. At work, I’ll do whatever’s needed.
rvz 1 days ago [-]
> Yes I won’t use LLM autocomplete or agents for any personal projects.
So you would use AI including LLM autocomplete at work, but at the same time, you don't want anything to do with it?
You just previously said that:
>> "...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."
That means you would still use AI at some capacity which breaks that guarantee.
This also means that you just contradicted yourself, when I explicitly said in any capacity that you would never use AI or agents at all.
dtj1123 15 hours ago [-]
People often do things they don't want to when at work.
NamlchakKhandro 22 hours ago [-]
Need to change the logo to one of a guy with a massive chin and a creepy stare.
colesantiago 1 days ago [-]
Honest feedback:
This is AI generated TUI slop made with claude.
I've been seeing a sad trend of these things being built with AI with no care and will be just abandoned in less than a month.
Why should I use this when I can use lazygit which is more popular and has been around and battle tested for years?
ICHx 19 hours ago [-]
Exactly, waste of electricity
TheSorcerer 11 hours ago [-]
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.
hoppp 1 days ago [-]
I like it but the donut animation is not needed, overbuilding gives AI slop vibes
I would love to use it without gimmicks.
jllyhill 24 hours ago [-]
Because it is, Claude is one of the two contributors. Just another slop project made farming HN points and marketing.
icase 1 days ago [-]
i appreciate that it’s not more rust slop, but i never understood the need for a git frontend.
jodysalt 13 hours ago [-]
I think it can be helpful sometimes when looking at large diffs.
I tend to use the tools in GitHub/Bitbucket. But, I can see how this could be a good alternative.
insane_dreamer 17 hours ago [-]
I started using lazygit a couple years ago, never looked back. It’s great
TheSorcerer 11 hours ago [-]
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
insane_dreamer 3 hours ago [-]
thanks for the info; will give it a try
fyi, a couple of features that lazygit does not have, or that aren't easily done in lazygit and which pycharm does quite well (I've used _many_ git tools, and IMO pycharm's internal implementation is still the best, but I switched to lazygit because I dropped pycharm for zed).
- diff any branch against any other branch (lazygit relies on certain branches being marked or inferred as main branches against which you can diff)
- see a file's git history (and which branches those commits are on), drill into the commits
- github (or gitlab, codeberg, etc.) support: open commit in github (easiest way to share commit with a co-worker, for example)
TheSorcerer 2 hours ago [-]
Thanks! Super valuable feedback!
I'll make sure to implement these features in the near future.
The branch diff is already there and works quite nice.
insane_dreamer 53 minutes ago [-]
another feature that pycharm has (and Zed though not as well implemented): insert the filename into the commit text.
zed inserts the filename but doesn't allow you to edit the commit (so it's all or nothing), pycharm allows you to edit the commit prepopulated with the filename if only one file is staged.
another enhancement is that neither pycharm or zed can handle inserting multiple filenames into the commit. so while editing the commit, you could potentially have keys to insert the staged filenames, i.e., by pressing a meta+number key combo where ctrl+1 inserts the first filename in the staged list, ctrl+2 the second, 1-9. just an idea.
TheSorcerer 1 days ago [-]
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.
jddj 1 days ago [-]
I can't really tell why this comment got flagged, so I've vouched it.
Maybe I've missed some context
projektfu 1 days ago [-]
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.
pageandrew 1 days ago [-]
> - Independent drill-downs in the Branches/Commits panels (deliberate, not a port artifact)
> (deliberate, not a port artifact)
Smells like AI
jddj 1 days ago [-]
Also lots of "genuinely" and some air quoted phrases which are another tell.
I guess you folks are right and it's probably the llm filter. I looked at the GitHub and thought it had too many screenshots to not have had some human effort, but who knows these days.
uproarchat 1 days ago [-]
If that's what happened, I wonder if the same filters exist for tools like Grammarly. Some people are English as a second language, and some people simply want to put the best foot forward and make the best first impression.
TheSorcerer 11 hours ago [-]
Thank you!
I've used AI to fix my English as it's not my primary language and probably got flagged.
And so it's "actually memory safe".
/sarcasm in case not obvious.
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.
With Claude, i find myself reaching for Magit even less.
Yes, smells like vibe code. Haven't looked inside but can already tell
Is that the principled position you want stand on in 2026 and beyond?
So you would use AI including LLM autocomplete at work, but at the same time, you don't want anything to do with it?
You just previously said that:
>> "...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."
That means you would still use AI at some capacity which breaks that guarantee.
This also means that you just contradicted yourself, when I explicitly said in any capacity that you would never use AI or agents at all.
This is AI generated TUI slop made with claude.
I've been seeing a sad trend of these things being built with AI with no care and will be just abandoned in less than a month.
Why should I use this when I can use lazygit which is more popular and has been around and battle tested for years?
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.
I would love to use it without gimmicks.
I tend to use the tools in GitHub/Bitbucket. But, I can see how this could be a good alternative.
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
fyi, a couple of features that lazygit does not have, or that aren't easily done in lazygit and which pycharm does quite well (I've used _many_ git tools, and IMO pycharm's internal implementation is still the best, but I switched to lazygit because I dropped pycharm for zed).
- diff any branch against any other branch (lazygit relies on certain branches being marked or inferred as main branches against which you can diff)
- see a file's git history (and which branches those commits are on), drill into the commits
- github (or gitlab, codeberg, etc.) support: open commit in github (easiest way to share commit with a co-worker, for example)
zed inserts the filename but doesn't allow you to edit the commit (so it's all or nothing), pycharm allows you to edit the commit prepopulated with the filename if only one file is staged.
another enhancement is that neither pycharm or zed can handle inserting multiple filenames into the commit. so while editing the commit, you could potentially have keys to insert the staged filenames, i.e., by pressing a meta+number key combo where ctrl+1 inserts the first filename in the staged list, ctrl+2 the second, 1-9. just an idea.
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.
Repo: https://github.com/simoarpe/ziggity
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.
Maybe I've missed some context
> (deliberate, not a port artifact)
Smells like AI
I guess you folks are right and it's probably the llm filter. I looked at the GitHub and thought it had too many screenshots to not have had some human effort, but who knows these days.
Just FYI a large portion is vibecoded for those that don't like that.