Hi Hacker news !<p>I’m Julien and I built an alternative CLI for Git : gut.<p>Even if I haven’t been coding for a long time (I’m in the first year studying computer science), I’ve always found git to be frustrating.
The command naming is inconsistent and git lets you easily shoot yourself in the foot.<p>I made gut, another git porcelain, to solve these issues.<p>It provides a consistent naming of command. To do so, syntax is based on subcommands. For example, to delete a branch, run gut branch rm rather than git branch -d, same to delete a remote (gut remote rm) and so on.<p>Gut also prevents you from shooting yourself. It provides nice defaults and always prompt you before doing something destructive.
Also, it won’t allow you to rewrite the history if it has been pushed to the remote. Creating commits in detached head is also prohibited.<p>Finally, git was made when GitHub and others didn’t existed yet. To diff commits, gut opens the compare view in the browser. And to merge a branch, gut opens a pull request.<p>I have been working on this project for the past few months and I am happy to be able to share it.<p>I hope you’ll like it. Any suggestions is welcome !<p>Repo: <a href="https://github.com/julien040/gut">https://github.com/julien040/gut</a>
Maybe it's just morning, or maybe I'm a luddite, or both, but my knee-jerk reaction to this was "why does anyone need this? Just learn git." But then I saw the "explain" command, and then I read that you're a new CS student.<p>That got me thinking about the first time I really screwed something up and had to figure out how to use git rebase, and the first time I tried to create a git submodule (back when submodules were new and there wasn't much help to be found on StackOverflow). I must have let the Stockholm syndrome set in, because the "explain" feature is a wonderful idea for students.<p>The dead-simplicity of it is very desirable in certain spaces. Back when I was in college, I wrote code for some indie visual novel games, and I was always the only person with a software development background. If I had a tool like this, it would have been MUCH easier for my colleagues to cooperate with me in the development process.
I like the attempt; git cli has a steep initial learning curve and thinking about the git interface and seeing if we can name & simplify it is worthwhile.<p>> Revert it without modifying history<p>Git revert modifying history is a feature!! It’s a safety net that allows you to, for example, revert the revert if the first revert was a mistake. Sometimes you don’t know the first revert is a mistake until later...<p>Likewise the undo command loses working tree progress just like git reset --hard, but I’m wondering is this the default behavior you want in an “easy” git wrapper?<p>What if a git wrapper designed to be easy also thought hard about how to make every single command safer than it is by default with git, for example, quietly making a backup of any work you want to undo or revert? Like maybe you could make branches with a special naming scheme so they’re normally hidden by the wrapper, and cleaned up later, but identifiable so you can bring them back. Or maybe the cli wrapper could provide a more intuitive & useable interface for the reflog.<p>One thing that would be useful with a git wrapper is a version of git stash that uses branches instead of the stash. This is because the stash is not in the reflog, and it doesn’t have the same level of safety that commits & branches do (the git stash manual mentions this). The biggest unintentional losses of code I’ve seen are git stash accidents, not counting people getting frustrated not knowing how to use git to fix a mess, and nuking their repo.
Congratulations on the launch Julien!<p>My history with git and GitHub is indeed chaotic. It took multiple steps and being explained with different approaches for me to finally understand the basics of git. Today, I consider myself proficient because I'm autonomous for 99% of what I want to do with git or GitHub, and honestly what you cover largely corresponds to these 99%.<p>You could add a feature flag for users to actually display the commands that gut runs in the background. Users would use gut to actually learn git with time, that would be very powerful and I would instantly recommend your tool to my students.<p>Again, kudos to your approach and execution.
Looks interesting, thanks for writing and posting.<p>I would suggest you go further and package all the branch related operations as subcommands of "gut branch". For instance, "gut branch ls" is more transparent and explicit than just "gut branch".<p>Also move the "switch" commands to "branch". Force branch creation to be explicit ("gut branch new") that does not change the current branch. That will prevent typos or memory lapses from leading to errant new branches. Then provide "gut branch switch branchname" that will only switch to an existing branch. You can include a "-f" flag to explicitly force branch creation, allowing a single command "create and switch" operation. You have in general avoided flags, but "-f" is extremely common and widely understood in the unix world.<p>Small changes like these can make significant improvements in the ergonomics of an interface that is already better than git's.
Git alternative command line interfaces just make no sense<p>1. If you want to do something advanced, it will be a lot easier to find help online using regular/original git commands<p>2. You still need to learn this new interface , so you will end up learning too different command line interfaces (one for the easy stuff and one for the advanced stuff)<p>3. You will surely, almost certainly mix the two interfaces<p>Use and learn git "original" commands to do advanced stuff
Use a nice UI for the easy straightforward stuff<p>The only alt command line interface I might consider is magit, because it mixed the emacs commands with GUI elements, and still i think magit is not all that because its not GUI enough, if magit becomes faster and more graphical, only then it might make more sense (for now its really only for emacs hardcore users)
Secrets management seems like a concern. It's really hard for developers to keep credentials and keys out of git. It looks like `gut save` adds anything that not already in .gitignore. Even less attention to the tracked files could make that worse.<p>I wonder if you could try to detect and warn about secrets, maybe via content inspection.
One use everyone here seems to ignore is that git has become a collaboration tool outside its immediate uses as a software development workflow. For people like me who don't need all the advanced uses but simply want to be able to version control some files, this simplified interface is excellent. Thank you.
I'm starting to get confused with all the git clients/wrapper out there I first thought you would be <a href="https://github.com/sdslabs/gut/">https://github.com/sdslabs/gut/</a> or maybe <a href="https://github.com/tillberg/gut">https://github.com/tillberg/gut</a> or <a href="https://github.com/quilicicf/Gut">https://github.com/quilicicf/Gut</a><p>Choosing a name is hard and all the gut ones are taken (haha...), but maybe at least choose one that isn't used multiple times for the same use case. You probably wrote kt for yourself and I name my programs however I like as well, but man you even registered a domain for it. Let's hope it finds more traction than all the other gut clients
> It provides a consistent naming of command.<p>Very nice.<p>> Gut also prevents you from shooting yourself.<p>Excellent.<p>> Finally, git was made when GitHub and others didn’t existed yet. To diff commits, gut opens the compare view in the browser. And to merge a branch, gut opens a pull request.<p>Eh... here you start to lose me. A lot of my repositories get pushed to a personal server (which for me personally is usually just a bare repo, but could be ex. gitea). On the hosted side, I use GitHub and GitLab, which you do support, but I also use sourcehut.<p>Finally, the telemetry is a big red flag for me. Opt-out is always a red flag, especially since you don't appear to signal it to the user up front. And under things collected at <a href="https://gut-cli.dev/docs/#64dc74dd-8a3d-44d6-aab7-55483519a853" rel="nofollow">https://gut-cli.dev/docs/#64dc74dd-8a3d-44d6-aab7-55483519a8...</a> , what <i>exactly</i> does<p>> The command you used<p>mean? Just which function is being called, or arguments as well? Because I would very much like to not be sharing things like branch names with a third party.
Pretty awesome. Been using git for 10 years and I trully think its CLI is terrible. It's unintuitive, scary, and opaque. I'll give it a go. Pretty cool for a first year student, you've gut (pun intended) a good career ahead of you I'm sure.
Regardless of the aim of the particular tool, I just want to say that the visual quality of the web page, documentation, and the quality of the content is excellent and I wish all the projects had this level of attention. Kudos!
There is a similar project, Gitless: <a href="https://gitless.com/" rel="nofollow">https://gitless.com/</a>
A maintained fork is here: <a href="https://github.com/goldstar611/gitless">https://github.com/goldstar611/gitless</a> (I use it)
I really like this. I think it takes a beginner to create this too—I know I wouldn't be capable of doing it since I'm just too used to git's terrible UX.
I know you're trying to avoid footguns - but how do you handle workflows where up-to-date rebases are required? Several repos I've been in ask for commits to be rebased to the latest branch for new changes to be PR'd in, and those require the `-f` flag after rebasing to rewrite the local history AFAIK.<p>Also I'm not too sure about the default opted-in telemetry, I definitely believe a prompt on install would be better in its stead.<p>Otherwise this looks like a cool project, not something I'd use but very neatly made. Kudos to pulling this off on your first year of CS!
I like that you worked on this but the git cli is already easy to use to be productive.<p>I use the same 5 commands over and over and am happy with that. And Ive met so many people where that’s the only cli command they use and they are non-dev, non-tech savvy people who learn their commands and go about their business.<p>Keep working on this, but I think highlighting other, more important features will help you connect with users. Easy to use doesn’t make it easy for me to distinguish your tool from other ways to use git.
The one thing I would reconsider is `gut revert`:<p>All other subcommands either don't exist in git, or do (almost?) exactly the same thing (gut/git switch). But `gut revert` is more of a `git reset` or `git checkout` rather than doing what `git revert` does.
I'm not sure that I like the fact that gut pushes the emoji thing onto users. IMO a good commit message will be descriptive enough that you really don't need an explanatory emoji. For example, if I have a commit titled "Add documentation for SomeAPIClass", I really don't need a book emoji in front of that, because I made it clear that it was documentation.<p>If you are going to add emoji to a git commit, make sure it's appropriate. For example, if you add a feature to your app that shows confetti, you might add a party popper emoji to the commit message, but you shouldn't litter your git history with emoji unnecessarily.<p>I guess I could continue ranting about the people who add "feat:", "chore:", and the like to their commit messages, but what I've written about emojis here really applies to the plaintext tags as well.
<a href="https://github.com/julien040/gut/blob/main/src/telemetry/telemetry.go">https://github.com/julien040/gut/blob/main/src/telemetry/tel...</a><p>In that file we find a URL:<p><a href="https://api-events.gut-cli.dev/v1" rel="nofollow">https://api-events.gut-cli.dev/v1</a> <-- If data about users is collected here, is there any legally binding agreement that covers how that data can be used. Is there even any knowing consent by the user that data will be collected.<p>Good luck with the computer science degree.<p>NB. I am not implying that consent or an agreement are legally required. The questions are asked because the answers could affect a user's decision whether or not to use the software.
I'm a fan of git, but I feel your pain regarding inconsistencies. Why o why is it:<p>`git log --oneline` and `git commit --no-edit`?<p>Why not `--one-line` or `--noedit`? Why a hyphen in one and not the other?<p>There are a lot of other such inconsistencies, but these are the two that I use and see the most.<p>Great project. Congratulations.
Seems like a cool project. Even after 15 plus years of using git I still get tripped up with some of the naming. I didnt check the internals but you mention not being able to rewrite if you push to remote. I think this is sort of a mistake because git has the lovely push force-with-lease that only force pushes if no other modifications have been made to the remote which is quite useful in a lot of scenarios
Weird that nobody has mentioned Game Of Trees[1] (aka got), which is developed by OpenBSD-related people and “prioritizes ease of use and simplicity over flexibility”, according to their main page.<p>[1]: <a href="https://gameoftrees.org/" rel="nofollow">https://gameoftrees.org/</a>
Thank you for all your feedback!
I have many great ideas for improving Gut, which I've detailed in a recent blog post.<p><a href="https://github.com/julien040/gut/blob/main/future_of_gut.md">https://github.com/julien040/gut/blob/main/future_of_gut.md</a>
Lovely idea & execution. I really like the landing page for this.<p>Not sure if it does already, but showing the user the equivalent git command would be a great way for them to learn git itself.
Love the idea. Git is a useful tool with the worst UX imaginable.<p>From a UX perspective, I really like using dialog[1] for console UIs. The use of color, formatting, shapes, arrow navigation, buttons, etc makes it visually very easy to understand, and functionally very quick and easy to use.<p><a href="https://www.geeksforgeeks.org/creating-dialog-boxes-with-the-dialog-tool-in-linux/" rel="nofollow">https://www.geeksforgeeks.org/creating-dialog-boxes-with-the...</a>
I feel `gut stash` is sorely missing from the list of commands. It's probably my most used command when iterating on a few ideas to see what works best
This looks very similar to bit CLI - <a href="https://github.com/chriswalz/bit">https://github.com/chriswalz/bit</a>
Something I learned a while ago is that if I can't remember the commands and args to any tool, not just git, I make a bash alias or function so it makes more sense to me and I don't have to remember all the things. In the end, there's still no substitute for learning the essentials about how a tool works.
Something like this has always been sorely needed. I don’t know if this is the right level of abstraction, if one could stay in Gut forever or is eventually required to step down and use git directly. But something like this, someday, has to come. We’ve been dealing with git’s terrible UI for way too long.<p>Congratulations and good luck
I'm in favour.<p>I'm constantly tinkering with my own Powershell wrapper for git - it's not publishable yet - but a goal for the project is to show the git commands being executed.<p>I'm focused on rebasing. I want to make it easier to clean up ugly history before review. I will have to check out your "undo" semantics.
Nice work on basically of all of this. Dope site, nice code, congrats on actually doing a project most people dont. I personally am not sure about the idea itself, but I think you probably gained an insane amount of valuable experience making this so thats worth more.
Can you add support for conventional commit[0]? It seems to be a more popular choice than gitmoji.<p>[0]: <a href="https://www.conventionalcommits.org/en/v1.0.0/" rel="nofollow">https://www.conventionalcommits.org/en/v1.0.0/</a>
This is cool and all and I hope people enjoy your project. But, for me, if I'm using a tool like git, I'd much rather use the native commands so I don't forget them if I'm working on a box that doesn't have other tools installed.
Hmm, I wonder if instead of using `gut`, adding the commands themselves to `git` as a plugin might get you more users.<p>For instance, redirect `git gut` or `git explain` namespace to your tool.
One thing I'll say is that naming this `gut` is not a great idea for a git alternative. `u` is one key away from `i`, so all it takes is a simple typo and your users will accidentally use git instead of your CLI!
Neat! How does this compare to <a href="https://github.com/git-town/git-town">https://github.com/git-town/git-town</a>? I’ve used `git-town` for ages but I’ll give `gut` a try!
Think something may be off on iPhone rendering. Your accordions don’t look quite right, I think:<p><a href="https://i.imgur.com/9mGrHpi.jpg" rel="nofollow">https://i.imgur.com/9mGrHpi.jpg</a>
> If you have years of muscle memory, gut is probably not for you.<p>yep, that's my problem.<p>i do really wish that one of these would take off though and everyone would switch, it would be better for the world.
I’m 100% behind the learning got part. But that’s just it: just learn git. Don’t make it easier by abstractions. Know and use the commands. It’s much better in the long term.
Let's just hope it's supposed to be pronounced as the German "gut" (as in good) rather than the English "gut" (as in curve)
I don't mean to come across as rude, but isn't this something that GPT can already do? I'm genuinely curious if there's any benefit to creating a tool like this when GPT already exists.<p>Edit: Used GPT to rephrase.
Please stop building git CLIs, just use LazyGit and be done with it:
<a href="https://github.com/jesseduffield/lazygit">https://github.com/jesseduffield/lazygit</a>
I definitely think it's a great idea to try and evolve how Git is used from the command line.<p>At my current job, I've decided to create my own wrapper around both Git and Jira based on the workflow I've settled into after all these years as a programmer.<p>Here's a list of subcommands I wrote:<p>`develop <jira id>`: Creates a new branch based on the name of the Jira ticket (referenced by the Jira ID) and moves the ticket to "In Progress." The Jira ID is appended to the branch name so the CLI will always know what ticket we're working with.<p>`undo`: Uncommits the last commit but leaves the changes intact. Effectively an alias for `git reset HEAD~1 --mixed`.<p>`open changes`: Opens all the files that have changed between the current branch and the main branch in VS Code.<p>`list changes`: Simply lists the files that have changed between current branch and main without opening them.<p>`open issue`: Shows the Jira issue for the current branch in the terminal.<p>`log`: A more condensed version of `git log`. Alias for `git log --oneline`.<p>`commit`: Either uses a supplied commit message or, if one isn't provided, defaults to using the title of the Jira ticket. Most of the time I supply a message, but at my company we want the first commit to always be the same format so that all squash+merges describe the overall PR.<p>`create pr`: Commits a changelog entry, creates a PR in GitHub, always making sure to use an optimally formatted title, and moves the status of the Jira ticket to "In Review." It also adds labels and kicks off a QA deployment.<p>`merge pr`: Merges the open PR for the Jira ID of the branch and moves the Jira ticket to "In QA."<p>`wip`: Commits all present changes, using "WIP" as the commit message, and skips any pre-commit hooks that might either slow things down or block the commit. Alias for `git commit -m "WIP" --no-verify`. Yes, I know about `git stash`, but I'm always paranoid of clearing the stash, and stashes aren't (easily?) associated with specific branches.<p>`update`: Fetches the latest changes on main and then rebases the current branch off it. Admittedly, I don't like this name.<p>`push`: Basically the same as `git push` except it will refuse to ever push to the main branch, even if `force push` is used. And `force push` will always use `--force-with-lease`.<p>`my prs`: Lists the PRs I have open. Alias for `gh pr list --author "@me"`.<p>`branch`: Unlike `git branch`, only returns the name of the current branch, which is also useful for doing things with the branch programmatically.<p>`branches`: Does what `git branch` does.<p>`lunch`: Sets my Slack status to say I'm at lunch with the hamburger emoji.<p>`search log`: Searches the log using what comes after the first argument. Alias for `git log -S${@:2}`.<p>I know not all of that had to do specifically with Git, but both simplifying some common Git commands and integrating with Jira has made my job a much happier one. Hopefully this either inspires others to make their own job-specific CLI or implements some of these things in a Git-specific tool.
First off, congratulations on entering the Computer Science!<p>Second, I am not sure what is a bigger joke here, the project itself and the OP's innocuous and cute self-promotion or the fact that this post landed the HN's front page.<p>0. Terms and definitions.<p>"You" refers not to the author of the tool but to the dear reader who happens to stumble upon this comment in the stream of random screen scrolling.<p>1. Comment body.<p>Couple of things about CS classes and specifically about programming classes. They will teach you everything but the most important engineering principles. And you'll have to adjust your learnings once you leave the campus gate behind and enter the wilderness of real tasks and challenges.<p>The first biggest lesson I learnt as a CS graduate was that the most beautiful, efficient and valuable software program is the one that does not exist, literally no code[0]<p>The second biggest lesson I learnt as a CS graduate was YAGNI[0]. You never ever write a single line of code, even touch the keyboard until you are absolutely sure you have exhausted all possible options to solve your problem without getting your hands dirty with programming.<p>The third biggest lesson I learnt as a CS graduate was RTFM[2]. It is so exciting to go to conferences and see people present fancy slides and watch youtube videos with lollipop coloured pictures explaining some complex topics in a eli5 style. Or read blog posts on a gazillion of websites posted by unknown unknowns but yet coming so convincing as if they were written by John Carmack or ChatGPT 5. But then none of them tell you the whole truth and show you the full picture. It is only official documentation, manuals and boring reference specifications that can help you find what you are looking for. And you will need to learn the skill of grinding hunderds of pages of badly styled refdocs to find that really nitty gritty quirky feature that consumed your whole day in finding out why your code does not work as expected. That's where you will start proceeding to the official docs and source code (if needed) before anything else (even Stackoverflow!).<p>There have been so many git wrappers around, you can probably try them all (tig, jj, gh-cli, gitui, lazygit, gix, you google it). But then, no matter how much effort their authors invest in those tools, there will always be inconsistency between git and its wrapper and you find yourself resorting to git to do what was supposed to be covered by the bespoke tool. And then you learn to respect git, understand its concepts as they were designed, learn some bash and git aliases[3], ditch all those tools (or the majority of them) and proceed with your personal tailored toolbox where if you find something odd you adjust it for your needs within 10 minutes and chill out.<p>[0] - <a href="https://github.com/kelseyhightower/nocode">https://github.com/kelseyhightower/nocode</a><p>[1] - <a href="https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it" rel="nofollow">https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it</a><p>[2] - <a href="https://en.wikipedia.org/wiki/RTFM" rel="nofollow">https://en.wikipedia.org/wiki/RTFM</a><p>[3] - <a href="https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases" rel="nofollow">https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases</a>
How do you define "consistent"? Consistent with what? Because at the moment it looks like it's using completely other terminology than the VCS I am used to.