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

https://github.com/bmf-san/ggc

65•bmf-san•6mo 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•6mo 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•6mo ago

How were you able to tell?

tcoff91•6mo 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•6mo ago

I really want to use something like Darcs or Pijul, but Pijul is not ready yet, AFAIK.

notnmeyer•6mo 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.

stouset•6mo ago

You can 100% use it with that workflow, and there is no problem in doing that. You could use other workflows but those are things you can pick up as you gain more familiarity.

What I would focus on is what it enables you to do that’s hard in git: editing and revising commits that you’re iterating on, extracting out a large block of work into smaller commits, or splitting unrelated work out into a separate branch without needing to do a bunch of stashing, jumping around between branches, rebasing, etc.

Hell, even just being able to switch branches without having to do a wip commit or mess around with the stash is worth the price of admission to me. And having all of my work tracked during a long rewrite even if I don’t think to make checkpoint commits along the way.

But yeah, I’d 100% focus on what new superpowers you can add to your existing workflow before trying to actually change your workflow.

tcoff91•6mo ago

Just dive in and force yourself to use it. Keep the branch based workflow until you are more comfortable with the tool. Then try more exotic workflows.

jj git fetch to pull upstream main.

jj rebase -d main to rebase your branch on main

As you add commits to your branch jj bookmark move to update the branch then jj git push -b branchname to push it to remote

Also I highly recommend a couple neovim plugins: hunk.nvim for splitting commits and jjdiffconflicts.nvim for resolving conflicts.

stouset•6mo ago

Yep. Having made the switch, I now see git (as a user-facing VCS) as a dead end.

It’ll take awhile for people to switch, but I think it will happen eventually. Invisible git compatibility means we don’t have to get everyone to switch all at once, and the benefits of primitives more aligned with the mental model of what we’re trying to do are undeniable.

cyberpunk•6mo ago

This is delusional. Sorry, but you’re only shifting git with dynamite at this point.

johnisgood•6mo ago

Problem with GitHub is that the VCS is in the name, so they would have to re-brand themselves (which might end up in losing loads of users) before they start supporting an alternative VCS.

I agree anyways, replacing Git is or would be a very difficult task in many cases.

That said, let us say I have a team of 3 people and we are starting a new project. We can definitely choose something other than Git, like Darcs (or later Pijul). If we use a project management software that only supports git, however, then that would be a very limiting factor. We probably would just continue using git, or use another project management software or I have no idea. I have used Git most of the time ever since I started using VCSs.

tcoff91•6mo ago

But that’s what’s so great about jj vs pijul: it supports git as a backend. So you still get to use GitHub and all the things that go along with git.

stouset•6mo ago

Git as a backend (with some amendments) is lovely and brilliant. Git as a front end is legendarily difficult to use.

Jujutsu has all the advantages with none of the downsides and—unlike the alternatives—adoption doesn’t need to happen all at once. Every single person who I’ve convinced to give it a meaningful shot has fully converted. That speaks volumes.

nine_k•6mo ago

No, git is not going away. It's not radically rejected. To the contrary, Jiujutsu builds upon git, and remains backwards-compatible, within reason.

It's like using Zig instead of C. You get a much better, handier tool, but you can interact with C very easily, transparently. You can mix and match.

Things like Monotone and Darcs were exquisite research projects, they tested many important ideas, but could not hope to become the standard. Jiujutsu does have this chance.

kccqzy•6mo ago

I yearned for something like jj before I knew of magit. I was very used to the hg way of doing things and so git is a downgrade. But with magit I'm satisfied enough that I haven't felt a need to switch. Going back to typing commands in a terminal felt backwards. And magit makes a lot of things easy, like splitting commits (u on the hunk and then c e c -a c), moving commits from one branch to a new branch (A s), and moving commits from one branch to another (r s). What makes jj better than magit?

tcoff91•6mo ago

magit can only be as good as git.

jj’s first class conflicts and the way it handles rebase offers a UX that’s not possible with git.

Like with jj rebasing a stack of branches is just a single command. In git you would have to rebase the branch at the top and then hard reset each branch pointer one by one. jj’s rebase is just more powerful than git’s. Like it doesn’t just rebase a linear series of commits it rebases merge commits, other sibling branches, etc… it’s absolutely mind blowing.

https://ofcr.se/jujutsu-merge-workflow/

Munksgaard•6mo ago

Rebasing a stack of branches in git can also be pretty simple, with --update-refs. There's a good article here: https://andrewlock.net/working-with-stacked-branches-in-git-...

tcoff91•6mo ago

Yeah but with jj it rebases all the like side quest experimental anonymous branches too. In git rebase is a list of commits to be picked. In jj it is just so much more powerful. In git you can’t rebase all 4 parallel PRs you have in flight and the octopus merge that you are working off of that merges them all together.

There’s workflows that I do with jj that are just completely impractical with git.

globular-toast•6mo ago

I'm a long time magit user and jj is basically just how I just git! At least close enough. I owe most of my git proficiency to magit. I understand how people are confused by just using the CLI. So I'm all for higher level tools like jj. Don't think I could give up the magit interface, though, unless there's something similar for jj?

bmf-san•6mo ago

Thanks! I didn’t know about Magit or jj — they both look really interesting, I’ll check them out.

Also, good point about the demo GIF. I’ll try updating it with a more complex example. Appreciate the feedback!

JdeBP•6mo 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...

johnisgood•6mo 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. :)

bmf-san•6mo ago

Ah, I hadn't noticed that — makes sense now that you point it out. I'll look into fixing it properly. Thanks a lot for the heads-up!

johnisgood•6mo ago

Check the parent of my comment, he was the one who found it. He offered more insight as well. He pointed out where the issue might be, and how to fix it.

awestroke•6mo ago

A terminal based CLI? As opposed to what?

osigurdson•6mo ago

I think they mean it is an interactive type terminal program (vs "one shot" as the git cli itself).

csmantle•6mo 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•6mo ago

CLI as a paradigm is not necessarily related to emulating 1980s DEC hardware.

bmf-san•6mo ago

Yeah, “terminal-based CLI” might’ve been a fuzzy phrase — I meant it’s an interactive command-line tool, not just a one-shot command like most git subcommands.

It’s somewhere between a minimal TUI and a CLI — no full-screen UI, but it does guide the user interactively.

Thanks for the discussion, made me realize I should clarify that better in the README.

nine_k•6mo ago

The most popular CLI today is the browser's address / search / everything-else input control.

nikolayasdf123•6mo ago

> Requirement: git command must be installed

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

nikolayasdf123•6mo ago

> cmd := c.execCommand("git", "branch", "--format", "%(refname:short)")

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

trwhite•6mo ago

I’m not sure I see from your example why? You’d expect any git client to have branch.

williamdclt•6mo 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•6mo 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•6mo 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•6mo 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•6mo 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•6mo 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•6mo 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•6mo ago

Is the performance overhead significant? Is it worse than calling out to an external program? Are there any benchmarks on this?

9rx•6mo 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.

johnisgood•6mo ago

Yeah, but for this project, why would you choose (as others stated they would or prefer) to call out to an external program instead of using https://github.com/libgit2/git2go (libgit2, FFI) for example? For what it is worth, there is also a pure Go implementation: https://github.com/go-git/go-git (pure Go).

Keep in mind the initial comment, which is "I would have used libgit2 myself in any languages.", and they claimed it is a bad idea due to performance, as opposed to calling out to an external program.

9rx•6mo ago

> and they claimed it is a bad idea due to performance

Which, as before, is nonsense.

johnisgood•6mo ago

Thank you, thought as much. I hope I will get a response from the person / people claiming this.

9rx•6mo ago

> I hope I will get a response from the person / people claiming this.

You want more nonsense...?

johnisgood•6mo ago

No, I want people to be informed well, and that requires me to hear their side so I can dispute them.

Many people has said they are thankful it calls out to "git" instead of using FFI, which I think is weird, but then there are others who go ahead and say that it is a worse thing to do, and I want people to know that no, it is not.

bmf-san•6mo ago

Yep, ggc is a wrapper around the git CLI — intentionally so.

I chose to shell out to git because it's fast, stable, and has great cross-platform support. Tools like go-git and libgit2 are interesting (and I’ve looked into them), but they come with their own tradeoffs like performance, features, and build complexity.

That said, I totally get the curiosity — thanks for the discussion!

9rx•6mo ago

> No, I want people to be informed well, and that requires me to hear their side so I can dispute them.

What's in it for them?

throwaway894345•6mo ago

The main reason I cited for avoiding CGo was the impact on the code base, not the performance overhead. I’m not advocating for shelling out to the Git CLI, but rather preferring go-git unless there is a compelling reason to avoid it.

throwaway894345•6mo ago

> It being a "bad idea" is nonsense.

The bad idea claim was principally about breaking cross and static compilation.

9rx•6mo ago

Principally, but not exclusively. It was also told to be a bad idea because of some insignificant performance overhead associated with cgo.

Which is especially funny as using go-git (which is known to be slow) and shelling out to git are apt to bring even greater performance overhead. As always, don't assume – measure!, but if we have to play the odds for the sake of an internet comment, libgit2 is likely to be the most performant option reasonably available, if there is some reason to think that performance is of concern here.

Added complexity in compiling is a tradeoff to consider, of course, but "bad idea" is also nonsense there. It requires a different set of priorities, but those priorities may very well be exactly what a project needs. — And maybe not even. The earlier comment brought a lot of assumptions without offering any background. There are theoretically other options available for libgit2. For example, using the Wasm build. While others have had success using Zig as the C-side compiler, which doesn't have all the messy baggage legacy compilers tend to carry (e.g. poor cross-compilation support).

Yes, measurement may offer reason why those are not suitable options, but missing in the comment is the measurement, or even what is trying to be measured! Instead, we got something that appears to be copy and pasted straight from a Rust advertisement.

throwaway894345•6mo ago

> Added complexity in compiling is a tradeoff to consider, of course, but "bad idea" is also nonsense there. It requires a different set of priorities, but those priorities may very well be exactly what a project needs.

Yes, there are cases in which CGo’s tradeoffs are appropriate, but you’re rebutting my claim that CGo is a bad default, so you need to show that CGo is appropriate in the default case (you went so far as to call it “nonsense”), not merely that there exists some project for which CGo’s tradeoffs are appropriate.

Zambyte•6mo ago

Jujutsu (jj) was using libgit, but they migrated away to wrapping the git cli several versions ago.

scosman•6mo ago

Naming suggestion; you’re too close to gcc for my brain to see the difference.

emigre•6mo ago

I agree!... Definitely confusing...

bmf-san•6mo ago

Yeah, I kinda thought the same when I picked the name. Didn’t expect it to trip people up this much though — might rethink it if it becomes a real issue. Thanks for the honest feedback!

donatj•6mo 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.

joshka•6mo ago

Pedantically, I think you probably would call this a REPL rather than a CLI

bmf-san•6mo ago

What does your daily Git workflow look like?

I'm curious how other engineers manage their Git setup and workflows in practice. Specifically:

1. Primary Git client: Do you mostly use the CLI, a GUI tool, IDE integration, or custom scripts? And why?

2. Workflow shortcuts: Do you follow the classic `git add → commit → push` step-by-step, or do you bundle them into a single alias or script?

3. Interactive tasks: How do you handle more interactive tasks like staging hunks, resolving conflicts, or browsing history?

4. Alias and script maintenance: If you maintain custom aliases or functions, how do you keep them organized and shareable?

I’d love to hear what works for you (and what didn’t). Tools, habits, setups — anything goes!

mvieira38•6mo ago

1- mostly CLI but I'll use VSCode for merge editing, I think it's very nice

2- no aliases, I want to be aware of every step

3- for browsing history I'll go to Github (at my current job), I think it's a more pleasant experience

4- I don't apply

sonkajarvi•6mo ago

1. CLI

2. I have two aliases: gs for "git status", and gap for "git add -p"

3. I use VSCode for resolving conflicts, and GitHub or gitk for browsing history

4. No maintenance. I add them by hand if they're missing

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

Show HN: I spent 4 years building a UI design tool with only the features I use

Show HN: If you lose your memory, how to regain access to your computer?

Show HN: R3forth, a ColorForth-inspired language with a tiny VM

Show HN: Smooth CLI – Token-efficient browser for AI agents

Show HN: Slack CLI for Agents

Show HN: FastLog: 1.4 GB/s text file analyzer with AVX2 SIMD

Show HN: Gigacode – Use OpenCode's UI with Claude Code/Codex/Amp

Show HN: Artifact Keeper – Open-Source Artifactory/Nexus Alternative in Rust

Show HN: I built a directory of $1M+ in free credits for startups

Show HN: A Kubernetes Operator to Validate Jupyter Notebooks in MLOps

Show HN: Falcon's Eye (isometric NetHack) running in the browser via WebAssembly

Show HN: Horizons – OSS agent execution engine

Show HN: Daily-updated database of malicious browser extensions

Show HN: BioTradingArena – Benchmark for LLMs to predict biotech stock movements

Show HN: 33rpm – A vinyl screensaver for macOS that syncs to your music

Show HN: Chiptune Tracker

Show HN: A password system with no database, no sync, and nothing to breach

Show HN: Micropolis/SimCity Clone in Emacs Lisp

Show HN: Local task classifier and dispatcher on RTX 3080

Show HN: GitClaw – An AI assistant that runs in GitHub Actions

Show HN: An open-source system to fight wildfires with explosive-dispersed gel

Show HN: Agentism – Agentic Religion for Clawbots

Show HN: Disavow Generator – Open-source tool to defend against negative SEO

Show HN: BPU – Reliable ESP32 Serial Streaming with Cobs and CRC

Show HN: Hibana – An Affine MPST Runtime for Rust

Show HN: Craftplan – I built my wife a production management tool for her bakery

Show HN: Beam – Terminal Organizer for macOS

Show HN: Total Recall – write-gated memory for Claude Code

Show HN: Agent Arena – Test How Manipulation-Proof Your AI Agent Is

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

Show HN: I spent 4 years building a UI design tool with only the features I use

Show HN: If you lose your memory, how to regain access to your computer?

Show HN: R3forth, a ColorForth-inspired language with a tiny VM

Show HN: Smooth CLI – Token-efficient browser for AI agents

Show HN: Slack CLI for Agents

Show HN: FastLog: 1.4 GB/s text file analyzer with AVX2 SIMD

Show HN: Gigacode – Use OpenCode's UI with Claude Code/Codex/Amp

Show HN: Artifact Keeper – Open-Source Artifactory/Nexus Alternative in Rust

Show HN: I built a directory of $1M+ in free credits for startups

Show HN: A Kubernetes Operator to Validate Jupyter Notebooks in MLOps

Show HN: Falcon's Eye (isometric NetHack) running in the browser via WebAssembly

Show HN: Horizons – OSS agent execution engine

Show HN: Daily-updated database of malicious browser extensions

Show HN: BioTradingArena – Benchmark for LLMs to predict biotech stock movements

Show HN: 33rpm – A vinyl screensaver for macOS that syncs to your music

Show HN: Chiptune Tracker

Show HN: A password system with no database, no sync, and nothing to breach

Show HN: Micropolis/SimCity Clone in Emacs Lisp

Show HN: Local task classifier and dispatcher on RTX 3080

Show HN: GitClaw – An AI assistant that runs in GitHub Actions

Show HN: An open-source system to fight wildfires with explosive-dispersed gel

Show HN: Agentism – Agentic Religion for Clawbots

Show HN: Disavow Generator – Open-source tool to defend against negative SEO

Show HN: BPU – Reliable ESP32 Serial Streaming with Cobs and CRC

Show HN: Hibana – An Affine MPST Runtime for Rust

Show HN: Craftplan – I built my wife a production management tool for her bakery

Show HN: Beam – Terminal Organizer for macOS

Show HN: Total Recall – write-gated memory for Claude Code

Show HN: Agent Arena – Test How Manipulation-Proof Your AI Agent Is

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

Comments