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.

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.

However, a first year college student building something and putting it out in public is a great achievement and something to be condemned.

I assume you mean "not condemned" or "commended" possibly?

    Gut will never allow you to modify the history pushed to a remote repository.

My standard work flow is that I have a branch for each change that I commit to without any form. I just use it to checkpoint myself. Yes I push those both as backup and to get CI to tell me things I broke while I keep working without having a full local build kill my machine from the load. At the end I squash, rebase and force push and then merge to master. In fact we only ever allow clean rebase "merges" to master, i.e. fast forwards.

I'm all for the consistency in commands in gut for newcomers. I absolutely recognize that not everyone can just learn a bunch of command sequences.

That said I do not "get" why people complain about git checkout to switch branches. Svn used that and so being compatible with that was important for adoption even if people today, that don't even know that svn ever existed, find it weird.

But crippling, no sorry basically removing, one of the awesomest feature of git is mind boggling. Not a space bar heater moment. Heck git even deals totally fine with someone having pulled the branch you force pushed. People might not, especially if they never experienced it, but git the piece of software does not break even if you do it.

You're starting from a foregone conclusion that both of the following are true:

1. everyone is familiar with Subversion's design

2. that particular design decision was a good one to begin with

They aren't, and it wasn't.

I'm not saying switch isn't better. I am saying checkout was not a bad choice at the time. Git changed a lot of things vs what people were used to. Keeping some familiarity is actually a good thing for adoption. For "finding yourself at home". That does not mean they couldn't have introduced switch right away of course but the rest is history as they say.

Also, I did reference SVN specifically but even they did not invent this interface and some people surely switched directly from CVS to git without the detour. Do I need to me tion RCS? And they even used the shorthand co instead ;)

So after all that said please do read the quotes around "get". I don't "get" why people complain about it. As in most people seem to do exactly what you just perpetuated as well: they completely ignore historical context and complain why something wasn't done ~20 years ago in a way that takes 2023 context into account.

Yeah right.

What you actually said is that you don't get why people complain about it.

> even they did not invent this interface

It doesn't matter who invented it. Bad is bad. That's my point.

> most people seem to [...] ignore historical context and complain why something wasn't done ~20 years ago

Historical context isn't completely irrelevant—if the question is how something came to be. People complaining aren't complaining about that, though. They're complaining that it's bad, no matter how it came to be. It's not wrong to do so, and it's weird to say you don't get why they would. "Because it's bad" is why. That's sufficient enough to have a complaint, and anything else is irrelevant.

We may have experienced different complaints. What I hear is complaints like "Why on earth would you ever make switching to a branch be `git checkout`, that makes no sense?".

Queue historical context: Well very easy. In historical context, that would have been intuitive for people that would be using a version control system like git, because they were used to using tools that did the exact same thing.

Same way as a 20 something that has never used anything but git would not "get" why I say: "What's wrong with just using checkout? I've used that for years and years and it's second nature, why would you make me memorize a different way now? Also tell me, why can't I switch other things than branches with git switch, like a tag?"

It's like ChatGPT hype. I totally don't "get" it. If you believe the hype, we're all out of work yesterday. But it's actual capabilities seem to be far more limited and while useful for certain things and able to speed up development time if used right, it does not live up to the hype. Now of course you will correctly point out that not everyone is saying that and you are right. Just like not everyone complains about git checkout like I mentioned. But they exist and if not the majority they're the loudest.

edit:

https://nullroute.lt/misc/xkcd/

I’ve actually seen the opposite where people dive into the details and kind of get lost, give up and end up with a fragmented mental model that leaves them afraid to touch it.

I think what programming (outside of even CS and CE) is lacking is an apprenticeship structure that starts on your first day on the job. That's all to say theory and practical application are always different but especially different in industry.

The whole point of software engineering is to write software that makes our lives better. Why would "deal with it" be the right answer to the horrific mess that is the Git UI?

If someone is having trouble learning how to use a lathe, that doesn't mean lathes are a "horrific mess" and need to be reworked, it means that person needs to learn more about the tool they're using and how to use it.

The frontend can be a ui or a cli like this with a good explain command.

It is important though that the final git commands are shown, such that you can learn, and find more details on the internet when needed.

So learn, yes, but whilst avoiding many initial pitfalls.

The best thing to learn about git is what the safety nets are, what commands do destructive edits, vs what commands do things you can undo. Once you know how to recover from all the non-destructive commands, you never have to stress about them again!

The reflog is weird and confusing at first, but once you know it’s here and a little about how to use it, all of a sudden you realize it’s pretty hard to lose things, as long as you commit them.

run "git log" to grab the commit hash

The really challenging parts of git IMO are around maintaining branches. Merge vs rebase, squash or no squash, when to back-merge, etc.

https://jonas.github.io/tig/

I'd love a command pallet where you could search for basic behavior in plain text like "reset my branch to GitHub's copy" or "only rebase two commits" and have it find the magic incantation.

[1]: https://blog.waleedkhan.name/git-undo/

Oh my god, I just realized this is ref-log (a log of references), and not re-flog (I'm not even sure what "to flog" is). No wonder I've never really understood why it's called that, I simply realized that I can look up older references to everything there by using it. Thank you!

It kinda needs separate command that shows you both reflog entries and commands that lead to it. Maybe merged with undo command so you could look at the history of operations, go back to that point, and get alert if you skip something already pushed upstream.

git rebase -i is essentially "undo" of sort but, uh, not a tool for faint hearts.

> git blame (git author)

I doubt people are confused by that

> I'd love a command pallet where you could search for basic behavior in plain text like "reset my branch to GitHub's copy" or "only rebase two commits" and have it find the magic incantation.

"git do" that just asks ChatGPT and pastes solution lmao.

- not just update `origin/branch` - not checkout `branch` and sync it with `origin/brach`

and it drives me crazy.

  git config --global alias.chpull '!f() { git checkout "$1" && git pull; }; f'

It's just so good. I don't know what I'd do without it.

Knowing the git enough to not need crutches is opposite of luddite.

But yeah, for devs sure, just read git book 2 or 3 times and if you're competent developer you'd probably get it just fine, once you get the concepts it's perfectly logical.

Just that not everyone is a developer wanting to use git for dev things and those UIs have place for that. I kinda wish there was more on the graphics side, like you can tell git how to diff binary files or even encrypted files but good luck explaining that to the non-coder trying to use it.

I still don't get developers complaining about it, it's your fucking main tool to work and about 10x easier than competence in any programming language, just learn it, you will use it longer than any piece of code you ever wrote most likely.

Suffice to say the complaints about git are alien to me. It seems that either devs need to know very little or everything to be safe. The middle ground falls under "knows enough to be dangerous"; you start getting over confident all fancy with your git moves and screw up. But nothing that can't be fixed.

> Revert it without modifying history

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...

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?

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.

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.

We're all professionals working in a professional environment. "Git jail" isn't a thing. The "Git courts" won't take away your ability to use Git.

If anything, this would be an opportunity for a senior engineer, you know the people that are supposed to mentor and role model juniors, to give guidance on how to revert in the future.

I've got more than a decade working with the tool and use rebase daily. Hasn't been a problem yet.

So if the author really means "git revert with a nicer user interface" then by all means have at it, although I don't see what anybody is disagreeing on.

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%.

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.

Again, kudos to your approach and execution.

It's a great idea. For now, you can run "gut explain <command>" to get the git equivalent. But it would be better to really show what's going on.

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".

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.

Small changes like these can make significant improvements in the ergonomics of an interface that is already better than git's.

"gut branch ls" is an alias of "gut branch", and to prevent unwanted branch creation, a confirmation prompt appears when a new branch is specified in "gut switch".

I still agree with your point, though; it would be more consistent to have everything under the "branch" command. I will consider these changes.

In git you can switch to a tag or commit in addition to a branch. There are different flags you may want to use depending on which type of ref you have so in the case that gut should only support switching branches moving the command may make sense, but if it supports arbitrary refs then moving it would not make sense. Looking at the switch code for gut `CheckIfBranchExists` does expect only branches so tags and commits are not supported in the current version. Relatedly, it looks like gut does not make an attempt to reconcile a dirty working tree with switch: if it's dirty you either abort the switch or throw away your changes, but it could be helpful to tell the user they could also stash the changes and make the switch when aborting or offer to stash instead of just throwing away the changes.

I should move this switch command under the branch command.

Additionally, it is a good idea to advise to stash changes; I will likely add it in the next release.

1. If you want to do something advanced, it will be a lot easier to find help online using regular/original git commands

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)

3. You will surely, almost certainly mix the two interfaces

Use and learn git "original" commands to do advanced stuff Use a nice UI for the easy straightforward stuff

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)

Couldn't you say the same for wrappers around an API ?

Git is very popular, there is ton of resources online on how to use it and learn it, and a lot of UI tools if you dont want to learn the cli at all

I would say if an API is as popular as Git, a wrapper would be a very hard sell

But if the API is considered old, legacy, or not very popular, then maybe a wrapper make sense, but then this would still be a niche case, if the API the is not used much, the wrapper would be used even less

The only solution is for Git itself to fix it, but that's very unlikely. We did get `git switch` but that's it. They'll never rename "the index" to something sensible (e.g. "draft") or make a sane way to delete remote branches.

I recommend just learning with a GUI (Git Extensions is good) so you don't have to deal with the abysmal CLI UX until you at least understand the DAG.

Lazygit is roughly similar to magit but it's written in go so it starts quicker if you don't already live in emacs.

I wonder if you could try to detect and warn about secrets, maybe via content inspection.

Secret detection seems hard. Maybe "gut save" should inform the user which file will be committed to prevent committing a credentials file, but it's probably not the right solution. I must look into that.

It takes a few minutes to install and then all your secrets and config will be in the environment, and will stay automatically up-to-date when there are changes.

Might be a way to cut out that particular failure mode when using Gut (which looks interesting btw--kinda like Git: the good parts).

1 - https://github.com/envkey/envkey

https://github.com/topics/secrets-detection

But the rule I preach everywhere is never to write credentials in your code. Even if it's your Hello World kind of a local small program to test out things.

Alternative: store the credentials in /tmp/my.password and load it in your program. Most programming languages make it easy.

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

Most of the clients I listed I knew from HN itself they were posted in the past and I first thought this was a repost :)

From a quick search in the pacman and ubuntu repository none of those packages (or for that matter any other package) has a binary called gut. So if your client will be a smash hit you could be the first ;) good luck with that

Very nice.

> Gut also prevents you from shooting yourself.

Excellent.

> 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.

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.

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 https://gut-cli.dev/docs/#64dc74dd-8a3d-44d6-aab7-55483519a8... , what exactly does

> The command you used

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.

Here is an example of what the data looks like in BigQuery: https://cln.sh/PRcGwd6M

Meaning it asks the user whether it may upload telemetry, yes or no? Because that would be fine, though I would think less of it for defaulting to yes.

Here is how it looks: https://cln.sh/rCmVtVhZ

It's cool to see a fork of it.

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.

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!

Regarding the telemetry, it is not opt-in by default. On the first launch, the CLI asks if the telemetry can be enabled.

Here is how it looks: https://cln.sh/rCmVtVhZ

https://gut-cli.dev/docs#9351504d-284d-4e59-81a1-465835682b3...

Additionally, consider removing telemetry data after a period of time for added privacy.

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.

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.

I think this idea is great, and from what I’ve seen your approach makes sense for my brain. I’m gonna give gut a go!

Edit: I have tried tutorials and stuff but for some reason advanced git stuff just doesn’t stick in my brain.

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.

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.

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.

https://github.com/julien040/gut/commit/a92e4c510d912deb490e...

https://github.com/Netflix/pollyjs/commits/master

Here I can quickly tell which commits are features or bug fixes, even if the rest of the message is slow/hard to parse.

Versus:

https://github.com/openai/whisper/commits/main

I sometimes need to parse a couple words before I can figure it out.

The emoji on the repo look quite varied, which is fun, but I think stricter use could be productive.

https://github.com/carloscuesta/gitmoji

In that file we find a URL:

https://api-events.gut-cli.dev/v1 <-- 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.

Good luck with the computer science degree.

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.

https://cln.sh/rCmVtVhZ

About the binding agreement, I don't really know about this. For me, because gut wasn't collecting any personal information, GDPR wasn't applied. But I can be wrong.

`git log --oneline` and `git commit --no-edit`?

Why not `--one-line` or `--noedit`? Why a hyphen in one and not the other?

There are a lot of other such inconsistencies, but these are the two that I use and see the most.

Great project. Congratulations.

[1]: https://gameoftrees.org/

https://github.com/julien040/gut/blob/main/future_of_gut.md

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.

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.

https://www.geeksforgeeks.org/creating-dialog-boxes-with-the...

I'm adding `gut stash` to the next command to implement.

It would be a lie to say that I wasn't inspired by some elements like "sync". But I still consider that gut and bit are not so similar. I hope there is no problem

Congratulations and good luck

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.

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.

[0]: https://www.conventionalcommits.org/en/v1.0.0/

I've opened a new discussion on GitHub about this feature: https://github.com/julien040/gut/discussions/38

For instance, redirect `git gut` or `git explain` namespace to your tool.

https://i.imgur.com/9mGrHpi.jpg

I think it's the margin being too big; on a desktop, it looks right, but on small screens like a phone, it looks weird.

When I have more time, I'll try to solve this. Thanks for showing me the problem.

yep, that's my problem.

i do really wish that one of these would take off though and everyone would switch, it would be better for the world.

I still hope Gut will help some people.

https://www.warp.dev/blog/introducing-warp-ai

https://githubnext.com/projects/copilot-cli/

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.

Here's a list of subcommands I wrote:

`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.

`undo`: Uncommits the last commit but leaves the changes intact. Effectively an alias for `git reset HEAD~1 --mixed`.

`open changes`: Opens all the files that have changed between the current branch and the main branch in VS Code.

`list changes`: Simply lists the files that have changed between current branch and main without opening them.

`open issue`: Shows the Jira issue for the current branch in the terminal.

`log`: A more condensed version of `git log`. Alias for `git log --oneline`.

`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.

`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.

`merge pr`: Merges the open PR for the Jira ID of the branch and moves the Jira ticket to "In QA."

`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.

`update`: Fetches the latest changes on main and then rebases the current branch off it. Admittedly, I don't like this name.

`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`.

`my prs`: Lists the PRs I have open. Alias for `gh pr list --author "@me"`.

`branch`: Unlike `git branch`, only returns the name of the current branch, which is also useful for doing things with the branch programmatically.

`branches`: Does what `git branch` does.

`lunch`: Sets my Slack status to say I'm at lunch with the hamburger emoji.

`search log`: Searches the log using what comes after the first argument. Alias for `git log -S${@:2}`.

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.

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.

0. Terms and definitions.

"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.

1. Comment body.

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.

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]

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.

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!).

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.

[0] - https://github.com/kelseyhightower/nocode

[1] - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

[2] - https://en.wikipedia.org/wiki/RTFM

[3] - https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases

I'm not sure I understand what you mean

To answer:

> 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.

It really is! Word for word.

That seems rather bot-like.

Perhaps dang should have a look at the comment history of that HN account and see if it has a habit of copying comments.

Especially because in the original thread on Reddit the question was already answered days ago. So it doesn’t really make sense to ask again.

Karma farming probably. Which in turn is useful in order to have a bunch of legitimate-looking accounts engage in paid upvotes.

Otherwise you might click the “contact” link on the bottom of the front page and send an email to the HN mods. Include a link to the comment in question and and a brief description, give it a subject like “Possible karma farming bot”.