11 ms·
Show HN: ggc – A terminal-based Git CLI written in Go
Hi HN,
I built ggc (https://github.com/bmf-san/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 https://github.com/bmf-san/ggc
Demo GIF: https://github.com/bmf-san/ggc#demo https://github.com/bmf-san/ggc#demo
Thanks!
- johnisgood 1y agoThis 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 1y agoHow were you able to tell?
- tcoff91 1y agoI 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 1y agoI really want to use something like Darcs or Pijul, but Pijul is not ready yet, AFAIK.
- notnmeyer 1y agoany 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 1y agoYou 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 1y agoJust 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 1y agoYep. 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.
- bmf-san 1y agoThanks! 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 1y agoThe 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/9e93ef8a87973cab916e37a9f45e0fae33b459e7/cmd/interactive.go#L71 https://github.com/bmf-san/ggc/blob/9e93ef8a87973cab916e37a9... * https://github.com/bmf-san/ggc/blob/9e93ef8a87973cab916e37a9f45e0fae33b459e7/cmd/interactive.go#L134 https://github.com/bmf-san/ggc/blob/9e93ef8a87973cab916e37a9...
- johnisgood 1y agoWhere 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 1y agoAh, 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 1y agoCheck 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 1y agoA terminal based CLI? As opposed to what?
- osigurdson 1y agoI think they mean it is an interactive type terminal program (vs "one shot" as the git cli itself).
- csmantle 1y agoFrom 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 1y agoCLI as a paradigm is not necessarily related to emulating 1980s DEC hardware.
- bmf-san 1y agoYeah, “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 1y agoThe most popular CLI today is the browser's address / search / everything-else input control.
- deleted 1y ago[deleted]
- nikolayasdf123 1y ago> Requirement: git command must be installed holdup... is this just a wrapper around git?
- nikolayasdf123 1y ago> cmd := c.execCommand("git", "branch", "--format", "%(refname:short)") oh my god. you have just wrapped standard git CLI. well, this is dissapointing.
- trwhite 1y agoI’m not sure I see from your example why? You’d expect any git client to have branch.
- williamdclt 1y agoNot 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 1y agoI'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 https://github.com/go-git/go-git
- throwaway127482 1y agoI'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 1y ago
- scosman 1y agoNaming suggestion; you’re too close to gcc for my brain to see the difference.
- donatj 1y agoI'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 1y agoPedantically, I think you probably would call this a REPL rather than a CLI
- bmf-san 1y agoWhat 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 1y ago1- 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 1y ago1. 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