hckrnws

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.

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.

I agree with the just learn git part.

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

> [...] great achievement and something to be condemned

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

There's also "condoned".

Also it forces you to never get rid of the training wheels it seems.

    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.

Yes, and voiding even more use cases, total deal breaker, leave that to your or remote's githooks if you need it.

xkcd://1172

While that's funny it's the opposite of what this is ;)

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.

> I do not "get" why people complain about git checkout to switch branches. Svn used that

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 don't think you understood what I was saying.

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.

> I am saying checkout was not a bad choice at the time.

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.

Now you removed my quotes from get. Tsk tsk :)

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.

I've never seen an xkcd URI scheme before. Huh.

edit:

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

I'm sure this was a typo, but I don't think you meant "condemned." Maybe "commended"?

i laughed at seeing that above too - who knows? in other industries it's common to lay the crap on the new guy but haven't experienced that as much in software

Refreshed before I commented to say this and saw your comment labelled "0 minutes ago". :)

Commended. Yes. Stupid autocomplete on the phone.

You remind me of my primary school teacher who had the tendency of condemning me for my achievements...

Great art is often unrecognised by people stuck in the rut of convention.

commended?

[dead]

I agree. I think first year college students building things and releasing them to the public ought to face possible jail time.

Got requires a mental model. I've tried to teach git without the mental model and it just doesn't work. There's a whole pack of people on the internet who refuse to learn the internals and complain incessantly about it. I don't think there's anything wrong with them, but it's a signal that for some folks conceptualizing what's in the docs is difficult for them. The explain command I think could go a long way in doing that, similar to how I used explain to learn SQL.

I have a fuzzy jpg level understanding of the internals and I do completely fine with ~10 git commands.

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.

My rough mental model is each ref is like a .zip of your source code. Branches point to these. When you commit you create a new ref, it points to it’s parent and the branch now points to it.

To what extent should educators be responsible for teaching Git? I learned just enough to push to master for my assignments, and handle merge conflicts. Profs didn't care if you knew Git, they cared if you know how red-black trees work, or how CANBus works.

If by educators you mean professors I think none. Git is very specific and teaching the various different VCS paradigms wouldn't really be helpful in learning Git specifically. I say that in light of the fact that (at least in the US) a university is responsible for teaching students theory, and we've about maxed CS and CE out in theory.

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.

Do you have a good guide to the mental model of git? I agree with you and I think that's what preventing me from getting more familiar with it.

They used to have a page that summarized it all, but now there's a book! https://git-scm.com/book/en/v2

"just learn git" unpacks to two different things - gaining an understanding of the git model and how the various operations query and modify the repository state, and learning the arcane minutiae of git's command line invocations. the former is indeed a very valuable part of levelling up as a developer; the latter is only useful insofar as you have to interact with the `git` command line tool. it has no intrinsic worth, and if someone would rather write and use `gut` instead, more power to them!

I agree with the just learn git part. We are all students when it comes to learning something new to you and this career is a constant stream of learning things. So my advice would be to deeply learn what your tools are doing and do that by trying out different things in a zero risk sandbox. Git is decentralized, you can setup a local repository that you can use for practice and to learn what is going on.

Git and its particular interface aren't deep facets of the universe we need to get used to, building better tools and exploring new interfaces is exactly what we should be doing. Sure, learn Git, but that's not a reason to give up on alternatives.

> this career is a constant stream of learning things

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?

It's not really "deal with it" it's "learn the tool to start using it effectively".

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.

If using the tool effectively is burdensome enough, then it's the same as "dealing with it".

Well, yes, but "enough" is doing a lot of heavy lifting there. Learning git is a large and steep learning curve, but the benefits from doing so outweigh the costs.

Sure but if you can make a tool that saves you 5 minutes of time on a lathe every time you use it, you may be a fool for not doing it. That's the whole point of building tools.

In industry they use CNC millers, I guess many workers found lathes too unhandy and slow.

An alternative frontend to git cli is a good idea, since several git command names are very counter-intuitive. Git checkout to switch to a branch that you already have checked out, git add for adding new files, for marking resolved as well as for staging. Git status only shows your local status without looking at the server.

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.

In my case, a lot of the complexity of Git is in the edge cases. Like, I rarely if ever have to revert, but when I do, it's very stressful to remember everything to get it right. This will certainly eliminate that occasional, but monumental, stress.

Revert is normally extremely safe, I’m curious why it’s ‘monumentally’ stressful?

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.

The revert command is a good, easy solution- "git revert <commit-hash"

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.

That's what tig is for.

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

IMO git would be way better with different naming and some UX improvements. Like a git undo[1] command, or renaming git reflog (git usage or git cmdlog), git blame (git author), and so on. Also stuff like the index, while great for experienced developers, leads to a lot of confusion early on.

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/

> git reflog (git usage or git cmdlog)

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!

To flog is to beat with a whip, so it might be both.

Or, trying to sell; "He was flogging his wares".

> git reflog (git usage or git cmdlog)

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.

I've been using git for years and do `rebase -i` daily, bisect many spooky commands. However, I still don't know how I can update a branch and switch to it in one motion:

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

and it drives me crazy.

Not aware of a built in way, but if you use bash or similar as your shell you can do an alias like

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

Didn't think about alias for this even though I have alias for many other things, that should prevent `direnv` from triggering between checkout and pull. Thanks.

Why is rebase such a reviled git command? It's so useful. Interactive rebase is essentially a centralized place for editing history: reordering, squashing, amending, rewording, dropping, merging, splitting. Pretty much anything anyone could ever want to do can be done with interactive rebase. Enable autostashing and explicit dropping of commits and there's basically no way to screw things up. In the event that does happen somehow, reflog shows previous heads and even notes the point where the rebase began, making it easy to hard reset.

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

Rebase (with or without -i) is one of my most used git commands. The one thing I still get confused with is whether I have to commit to continue or not.

It's so easy to end up in rebase hell where you're constantly fixing the same diffs. If you know what you're doing and can get the rebased commits to be pretty small it's okay. Although I've recently started using merge commits again and just squashing my branch when I merge into main.

I agree with learn git, but learning git doesn't make git's CLI good. I would love a CLI equivalent of magit that I could recommend to people.

Have you heard of LazyGit? It's a Git TUI.

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

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.

I think in general, git is not a great tool for developers. If non-developers are required to use git, I think you may have a process problem. However, if that's the state of things, I think non-developers are probably better served by a GUI than a CLI command.

My first reaction was "git already has an easy to use CLI!" But reading a bit more of the post I definitely see how many things I don't think about anymore aren't as intuitive to a newcomer. And hats off to this student for making themselves a tool. (Probably ended up learning a lot about git in the process too.)

I work with approx 10 junior developers they use basic push/pull/commit/checkout/cherry-pick git, have no idea how it works, only what it does. Their training composed of looking at a wiki intro and some hand holding. In 10 years by far the biggest git related issue is quality of commit messages... (and maybe the commit content)

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.

[dead]

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.

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

Agreed, don't want to discourage this project as it is helpful to have more tools to learn the rather deep and complex Git interface, but changing Git functionality under the hood is a big no-no in my mind. Using this tool on an existing Git repository and rewriting history could get the book thrown at you by more senior engineers.

> get the book thrown at you by more senior engineers.

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 rewrite history all the time. And this is just porcelain. No one will be able to tell whether you rebase/reset/amend or use it.

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

The original claim makes no sense to me, nor does your complaint; `git revert` specifically creates new history rather than trying to do something rebase-like and change history/force push. That's why it's easy to revert the revert. Yes, I highly recommend git revert.

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.

Congratulations on the launch Julien!

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.

Thank you!

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.

Looks interesting, thanks for writing and posting.

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.

Thank you for pointing this out.

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

> Also move the "switch" commands to "branch".

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.

To switch to a commit, run "git goto <commit Hash>". However, you cannot switch a tag.

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.

Git alternative command line interfaces just make no sense

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)

> Git alternative command line interfaces just make no sense

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

I would say it depends

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

I agree. The Git CLI and terminology is awful, but it's the one that everyone uses. If you make a better unofficial interface you'll just make it harder because now you need to know both systems and can only search for one.

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.

Yea I want to like this but I can't. This is one area where in a lot of ways we're lucky. Git is pretty standard tool across the board. Learn it once cry once? I would also add you can probably learn 90% of what you need to do on a day to day basis in a day or two. Sure there's more oddball stuff but sometimes it's easier to just do it the brute force way e.g. reset everything and manually change shit to how you want it.

More like learn it once, cry forever. I will never not be irritated that push and pull aren't really opposite in git, and that's hardly its worst wart.

I'd also plug lazygit. I didn't grow up with line editors. When the state has multiple lines I'd rather see it all at once in a window rather than peek at bits and then have to remember the context in my head.

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

Someone here on HN wrote once that he uses Intellij for it's Git interface. Idea and PyCharm Community editions are free. Worth checking out IMHO. I use Intellij, but can totally understand if it is not evereyones' cup of tea.

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.

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

Yes, I definitely didn't think about this issue.

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.

If anyone needs help keeping secrets out of git, you could give EnvKey[1] a look (disclaimer: I'm the founder). It aims to keep all secrets out of the repo completely so that you can't be burned by forgetting to add something to .gitignore or other mistakes along those lines.

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

There's some open source tools that attempt to help, but yeah, it's a hard problem.

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

I know how it works in practice...

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.

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 https://github.com/sdslabs/gut/ or maybe https://github.com/tillberg/gut or https://github.com/quilicicf/Gut

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

I didn't know these projects existed. I took gut because on an AZERTY keyboard, the two letters closest to I are U and O. But O would have given got which is a Node.JS library. I hope this project won't conflict with anyone using other software called gut.

My first intuition why someone would use gut was that it's german for good so a "good" git client.

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

I wish there was a scalable solution to the naming problem. I totally get why the NSA would name their tools ETERNAL BLUE, DOUBLE PULSAR or some such. They probably have a name generator.

> It provides a consistent naming of command.

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.

Hi, I am considering removing telemetry because it appears to be a major issue. When Gut is launched for the first time, it collects consent and the user can opt-out at any time by running "gut telemetry disable". Arguments are not logged.

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

> When Gut is launched for the first time, it collects consent

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.

Yes, it asks if telemetry can be enabled.

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

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.

It's nice. Thanks!

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: https://gitless.com/ A maintained fork is here: https://github.com/goldstar611/gitless (I use it)

A great deal of inspiration comes from GitLess; it is an excellent project.

It's cool to see a fork of it.

Other similar projects are https://github.com/arxanas/git-branchless and https://github.com/martinvonz/jj.

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.

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!

Honestly, some workflows seem complex and I don't think I have the necessary experience to handle them. I think this case falls under "gut can't handle that and you must use git".

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

Consider editing the docs to state that telemetry is not enabled by default; I'm more interested in software that respects privacy and adding that to the docs would be a positive for me.

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

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

I've added this to the docs. Thank you for pointing this out

I like that you worked on this but the git cli is already easy to use to be productive.

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.

To provide an alternative perspective, I’m a self taught dev and use the same 5 git commands every day - but I’m not happy with that and I always feel intimidated and lost when I have to step outside of my git comfort zone.

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.

Are you kidding me? I've been using git for ~15 years, and I'm productive with it. But it's hardly easy to use and the incantations you have to remember to perform common operations are bizarre.

I'm going to think about it because I don't know how to focus communication around the project. What features to highlight. Thanks for suggesting this issue

The one thing I would reconsider is `gut revert`:

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.

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.

Yes, I thought about this. Some users may not want to use emojis in their commit messages. I have added a feature (or a bug fix) to allow writing a commit without any emojis.

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

For me it's about how fast I can read though a list of commits and get a sense for what happened. A uniform prefix really helps if you need to write release notes, for example. Check out:

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.

I am just impressed that the author was able to consistently think of relevant emojis for 100+ commit messages.

Actually, I never did. I use Gitmoji:

https://github.com/carloscuesta/gitmoji

https://github.com/julien040/gut/blob/main/src/telemetry/tel...

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.

AFAICT the telemetry does not collect PII, so I don't believe even by the spirit of recent data laws that any sort of agreement or even consent is necessary.

By default, telemetry is not enabled. On first launch, it will ask you if you want to enable it.

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.

IANAL but you're not wrong. An app "communicating with a server" is a totally normal thing to do even if it's diagnostic information & usage metrics. You just can't scrape people's PII out of their home directory and dump it on a server without consent.

I'm a fan of git, but I feel your pain regarding inconsistencies. Why o why is it:

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

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

Will give this a try. I'm a git noob and am intimidated by git, so I'll take a simple interface any day. Also, beautiful web page design.

Thank you !

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.

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

Thank you for all your feedback! I have many great ideas for improving Gut, which I've detailed in a recent blog post.

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

Lovely idea & execution. I really like the landing page for this.

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.

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

Thank you for the suggestion.

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

This looks very similar to bit CLI - https://github.com/chriswalz/bit

Oh I love your tool. The autocomplete is great.

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

I’m glad you pulled inspiration from it! Thanks for continuing the push to improve the git user experience. Looks very clean.

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.

Congratulations and good luck

I'm in favour.

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.

It's quite cool. That said, I wonder why git doesn't leverage those porcelain to improve itself.

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.

what do you question, legitimately curious?

The need, actual long term use of a tool like this, whether or not this a potential dark pattern tool, the high potential for bugs/easy misuse causing unintended things to happen.. I havent thought too hard about it but something along those lines was what came to mind as I looked at the repo. For sure some of my thoughts are probably wrong, and i may be too harsh

Can you add support for conventional commit[0]? It seems to be a more popular choice than gitmoji.

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

Thanks for suggesting this.

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

I like the sensible names. It would have made it more easier to grasp the basics and recallable.

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.

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 https://github.com/git-town/git-town? 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:

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

I had the same thought on my phone, but I couldn't find the issue.

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.

> If you have years of muscle memory, gut is probably not for you.

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

Simple and nice webpage design and cool tool as well :D Well done!

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)

Awesome! And you probably learn the GIT commands in the meantime. Good job sharing too!

I think this is great. Well done

This is awesome! Great job!!!

User-friendly Git CLI is GUI

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.

Edit: Used GPT to rephrase.

Probably, I made Gut before Warp AI or Copilot for CLI were announced. However, I think we can say the same about Stack Overflow. It can also help resolve your Git struggles.

I still hope Gut will help some people.

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

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

Please stop building git CLIs, just use LazyGit and be done with it: https://github.com/jesseduffield/lazygit

Lovely website <3

Ohh nice ! commandline for a commandline.

Lovely website!

Git gud with git or get gut ?

I definitely think it's a great idea to try and evolve how Git is used from the command line.

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.

Is git a problem that needs solving? It’s not that difficult to learn/lookup commands.

Yes. Git is inscrutable. It's become a cliche for teams to have one person that actually understands git well enough to unfuck it for other team members when things go sideways. Dan Luu has written about this, I think.

Just learn to use git.

There already is an easy to use cli for git. It's called `git`

First off, congratulations on entering the Computer Science!

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

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

I'm not sure I understand what you mean

I thought git was the CLI for git?

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.

That's funny, it's the same comment I received on another website: https://old.reddit.com/r/golang/comments/11usyyy/comment/jcq...

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's the same comment I received on another website

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.

I looked at a couple comments. They are in fact copying Reddit comments to HN, and it seems to have been a mildly successful strategy for... what exactly I'm not sure.

> a mildly successful strategy for... what exactly I'm not sure.

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

I hope the moderation is aware. I don't know HN very well. Is there a way to warn them of the problem?

Sometimes HN moderator dang will notice when his name is mentioned.

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

I read this as "every command leaves your repository in a state where you can finish your tasks using the standard git command".

You know another easy-to-use CLI for Git? Git.

Ah yes, git is so "easy to use" that there are a million tutorials, tutorials, and explainers for basic functionality. At this point, it is widely accepted that git is a very poorly designed CLI sitting on top of a fantastic tool.

You think so? I can't think of many other interfaces that have a site like https://ohshitgit.com dedicated to them.

mercurial was essentially a more intuitive version of git. too bad it wasn't more widely supported.