frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

XMLUI

https://blog.jonudell.net/2025/07/18/introducing-xmlui/
111•mpweiher•2h ago•59 comments

Coding with LLMs in the summer of 2025 – an update

https://antirez.com/news/154
141•antirez•4h ago•131 comments

The old Caveman Chemistry website (1996-2000)

https://cavemanchemistry.com/oldcave/
20•marcodiego•1h ago•0 comments

A Tour of Microsoft's Mac Lab (2006)

https://davidweiss.blogspot.com/2006/04/tour-of-microsofts-mac-lab.html
106•ingve•5h ago•13 comments

Java was not underhyped in 1997 (2021)

https://dylanbeattie.net/2021/07/01/java-is-criminally-underhyped.html
42•SerCe•3d ago•29 comments

LLM architecture comparison

https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison
197•mdp2021•9h ago•13 comments

When is it the best time to post on Show HN?

https://www.myriade.ai/blogs/when-is-it-the-best-time-to-post-on-show-hn
8•BenderV•55m ago•8 comments

Async I/O on Linux in databases

https://blog.canoozie.net/async-i-o-on-linux-and-durability/
136•jtregunna•9h ago•56 comments

Digital vassals? French Government 'exposes citizens' data to US'

https://brusselssignal.eu/2025/07/digital-vassals-french-government-exposes-citizens-data-to-us/
45•ColinWright•4h ago•8 comments

A human metaphor for evaluating AI capability

https://mathstodon.xyz/@tao/114881418225852441
92•bertman•7h ago•9 comments

How Tesla is proving doubters right on why its robotaxi service cannot scale

https://www.aol.com/elon-gambling-tesla-proving-doubters-090300237.html
100•Bluestein•2h ago•143 comments

Show HN: MCP server for Blender that builds 3D scenes via natural language

https://blender-mcp-psi.vercel.app/
99•prono•10h ago•37 comments

Behind the ballistics of the 'explosive' squirting cucumber

https://phys.org/news/2025-07-ballistics-explosive-squirting-cucumber.html
36•PaulHoule•2d ago•4 comments

The landlord gutting America’s hospitals

https://www.motherjones.com/politics/2025/07/the-landlord-gutting-americas-hospitals/
8•hhs•34m ago•0 comments

Dual interfacial H-bonding-enhanced deep-blue hybrid copper–iodide LEDs

https://www.researchsquare.com/article/rs-4114691/v1
7•gnabgib•3d ago•1 comments

I'm betting against AI agents, despite building them

https://utkarshkanwat.com/writing/betting-against-agents/
251•Dachande663•7h ago•147 comments

Show HN: ggc – A terminal-based Git CLI written in Go

https://github.com/bmf-san/ggc
37•bmf-san•4d ago•27 comments

Hungary's oldest library is fighting to save books from a beetle infestation

https://www.npr.org/2025/07/14/nx-s1-5467062/hungary-library-books-beetles
159•smollett•4d ago•21 comments

Make Your Own Backup System – Part 1: Strategy Before Scripts

https://it-notes.dragas.net/2025/07/18/make-your-own-backup-system-part-1-strategy-before-scripts/
309•Bogdanp•20h ago•97 comments

How the 'Minecraft' Score Became Big Business for Its Composer

https://www.billboard.com/pro/how-minecraft-score-became-big-business-for-composer/
45•tunapizza•4d ago•16 comments

Death by AI

https://davebarry.substack.com/p/death-by-ai
447•ano-ther•1d ago•178 comments

The bewildering phenomenon of declining quality

https://english.elpais.com/culture/2025-07-20/the-bewildering-phenomenon-of-declining-quality.html
300•geox•7h ago•523 comments

Nobody knows how to build with AI yet

https://worksonmymachine.substack.com/p/nobody-knows-how-to-build-with-ai
446•Stwerner•1d ago•353 comments

Robot metabolism: Toward machines that can grow by consuming other machines

https://www.science.org/doi/10.1126/sciadv.adu6897
23•XzetaU8•7h ago•15 comments

I tried vibe coding in BASIC and it didn't go well

https://www.goto10retro.com/p/vibe-coding-in-basic
144•ibobev•4d ago•151 comments

Beyond Meat fights for survival

https://foodinstitute.com/focus/beyond-meat-fights-for-survival/
145•airstrike•16h ago•358 comments

Can Software Be Durable?

13•maraoz•2h ago•16 comments

How to run an Arduino for years on a battery (2021)

https://makecademy.com/arduino-battery
87•thunderbong•3d ago•23 comments

Local LLMs versus offline Wikipedia

https://evanhahn.com/local-llms-versus-offline-wikipedia/
288•EvanHahn•23h ago•171 comments

Roman Roads Research Association (UK)

https://www.romanroads.org/index.html
27•countrymile•9h ago•5 comments
Open in hackernews

Show HN: ggc – A terminal-based Git CLI written in Go

https://github.com/bmf-san/ggc
37•bmf-san•4d ago
Hi HN,

I built ggc (https://github.com/bmf-san/ggc), a terminal-based Git CLI tool written in Go.

ggc provides: - A fast interactive UI (like `fzf`) for common Git operations

- Traditional subcommands (e.g. `ggc add`, `ggc commit`)

- Git-compatible config support (`ggc config` reads from `git config`)

- Built-in aliases and workflow automation (e.g. `ggc addcommitpush`)

The goal is to improve developer productivity by combining interactive workflows with scriptable CLI operations.

It's still under active development, but I'd love feedback from the community!

GitHub: https://github.com/bmf-san/ggc Demo GIF: https://github.com/bmf-san/ggc#demo

Thanks!

Comments

johnisgood•5h ago
This is not intended to be an insult of any sort, but I am pretty sure the use of LLM to write this was not so moderate, but I have nothing against it, you have a working project. I have done the same with projects similar to this.

I use lazygit (also written in Go) and magit a lot, they are quite nice. For GUI, I use Git Cola.

I wish the demo GIF was something more complex, perhaps adding & removing a particular chunk and committing it or something like that.

emigre•3h ago
How were you able to tell?
tcoff91•1h ago
I loved using Magit. It’s awesome.

But these days, I’ve moved on to jujutsu, a git-compatible version control system with much better primitives than git.

If you haven’t tried jj, I highly recommend it. The first-class conflicts and powerful but simple primitives for editing the commit graph are amazing.

It makes stacking branches an absolute breeze compared to git. And since it is git compatible nobody on your team has to change how they work.

johnisgood•1h ago
I really want to use something like Darcs or Pijul, but Pijul is not ready yet, AFAIK.
notnmeyer•58m ago
any advice on learning jujutsu? i keep bouncing off tutorials and blog posts about it. i’ve had a difficult time trying to map the github-centric branch-based workflow to jj. i’m sure part of the problem is “don’t try to use it like git”, but i haven’t gotten to the aha moment where it clicks.
JdeBP•5h ago
The display weirdness (e.g. the Z shell's percent character showing up) that you are seeing in your demo is because you are putting the terminal line discipline into raw mode, raw mode of course does not do CR-before-LF stuffing, and there's some confusion in the code as to when it does and when it does not explicitly emit CRs.

* https://github.com/bmf-san/ggc/blob/9e93ef8a87973cab916e37a9...

* https://github.com/bmf-san/ggc/blob/9e93ef8a87973cab916e37a9...

johnisgood•5h ago
Where is the "%" showing up? I only see it before he runs ggc. It is common to use "%" instead of "$" in some shells.

In particular, C Shell (csh) and Tcsh uses "%" as the prompt character. Common in BSD systems.

Of course you can customize Zsh (or Bash) to show "%", too.

Edit: never mind, I noticed it when he quit "ggc". My bad. :)

awestroke•5h ago
A terminal based CLI? As opposed to what?
osigurdson•3h ago
I think they mean it is an interactive type terminal program (vs "one shot" as the git cli itself).
csmantle•3h ago
From the GIF in the repo I think it's somewhere between CLI and TUI -- it's interactive but does not try to draw windows/surfaces in the terminal. But the borderline is fuzzy, so yeah
frou_dh•1h ago
CLI as a paradigm is not necessarily related to emulating 1980s DEC hardware.
nikolayasdf123•4h ago
> Requirement: git command must be installed

holdup... is this just a wrapper around git?

nikolayasdf123•4h ago
> cmd := c.execCommand("git", "branch", "--format", "%(refname:short)")

oh my god. you have just wrapped standard git CLI. well, this is dissapointing.

trwhite•4h ago
I’m not sure I see from your example why? You’d expect any git client to have branch.
williamdclt•3h ago
Not sure what you expected? That's the case for all git clients (is there any using libgit?) and almost certainly the right thing to do
ultramann•3h ago
I'm aware of go-git [0] which

> aims to be fully compatible with git, all the porcelain operations are implemented to work exactly as git does

written in pure go, therefore with a go native api.

I've never tried to use it, but it does look quite impressive to me.

[0] https://github.com/go-git/go-git

throwaway127482•2h ago
I've used it - it's lacking a ton of features. Another commenter in this thread said it's very slow compared to the git CLI, which is not surprising given that git is written in C.
throwaway894345•1h ago
I’ve used it for a production service. I thought it was surprisingly robust/featureful. There was one issue I ran into, but IIRC it was a limitation in the library’s filesystem abstraction, not a missing feature.
notnmeyer•56m ago
it’s slow, not great. at a previous place we used go-git and wound up switching to just shelling out to git.
johnisgood•2h ago
I would have used libgit2 myself in any languages. If bindings do not exist, I would have made the bindings first. There is no way I would have called out to an external program.

Someone mentioned https://github.com/go-git/go-git. I would have definitely used it unless there are better alternatives. If - as someone who claimed - it turns out it is slow, I would have created my own bindings to libgit2 still, most likely.

throwaway894345•1h ago
Binding to C in Go is a bad idea typically. There’s performance overhead, but more importantly your library (and everything downstream) also loses the ability to do nice things like fast compile times or easy cross compilation. You also likely introduce a runtime dependency on libc if not libgit2, so you have some DLL hell to deal with.
johnisgood•1h ago
Is the performance overhead significant? Is it worse than calling out to an external program? Are there any benchmarks on this?
9rx•56m ago
> Is the performance overhead significant?

How do you define significant? It is noticeable as compared to C. It is nothing compared to Python.

> Are there any benchmarks on this?

You will see an additional ~20ns per call (assuming the gc compiler; tinygo, for example, can call C functions as fast as C can). In other words, you're not ever going to notice unless you're making millions of calls in a hot loop. The bigger problem in a highly concurrent environment is that blocking C functions can start to mess with the scheduler if they are slow to return. You, again, would never notice in a program of this nature, though. The feature is there to be use. It being a "bad idea" is nonsense.

Some added pain in compilation is, fairly, a tradeoff to consider. But that's just because C compilers, for the most part, aren't very good. It is not like those problems go away if you use C instead.

Zambyte•1h ago
Jujutsu (jj) was using libgit, but they migrated away to wrapping the git cli several versions ago.
scosman•3h ago
Naming suggestion; you’re too close to gcc for my brain to see the difference.
emigre•3h ago
I agree!... Definitely confusing...
donatj•3h ago
I'm kind of relieved to see that it calls out to the native git binary. There is a popular pure-Go git implementation that is in my experience very slow.