[HN Gopher] Show HN: Gut - An easy-to-use CLI for Git
___________________________________________________________________
Show HN: Gut - An easy-to-use CLI for Git
Hi Hacker news ! I'm Julien and I built an alternative CLI for Git
: gut. 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. I made gut, another git
porcelain, to solve these issues. 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. 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.
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. I have been working on
this project for the past few months and I am happy to be able to
share it. I hope you'll like it. Any suggestions is welcome !
Repo: https://github.com/julien040/gut
Author : julien040
Score : 261 points
Date : 2023-03-30 12:18 UTC (10 hours ago)
(HTM) web link (gut-cli.dev)
(TXT) w3m dump (gut-cli.dev)
| amar-laksh wrote:
| Please stop building git CLIs, just use LazyGit and be done with
| it: https://github.com/jesseduffield/lazygit
| wseqyrku wrote:
| 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.
| julien040 wrote:
| 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/
| djaouen wrote:
| This is awesome! Great job!!!
| LorenDB wrote:
| 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.
| xtreme wrote:
| I am just impressed that the author was able to consistently
| think of relevant emojis for 100+ commit messages.
| julien040 wrote:
| Actually, I never did. I use Gitmoji:
|
| https://github.com/carloscuesta/gitmoji
| julien040 wrote:
| 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...
| 8organicbits wrote:
| 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.
| ryukoposting wrote:
| 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.
| hardwaregeek wrote:
| 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/
| markussss wrote:
| > 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!
| wlonkly wrote:
| To flog is to beat with a whip, so it might be both.
| adql wrote:
| > 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.
| matheusmoreira wrote:
| 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.
| hardwaregeek wrote:
| 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.
| 0x457 wrote:
| 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.
| kodah wrote:
| 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.
| hangonhn wrote:
| 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.
| kodah wrote:
| They used to have a page that summarized it all, but now
| there's a book! https://git-scm.com/book/en/v2
| globular-toast wrote:
| 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.
| FreeFlyFall wrote:
| Have you heard of LazyGit? It's a Git TUI.
| matt_s wrote:
| 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.
| bachmeier wrote:
| > 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?
| Xelynega wrote:
| 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.
| badrequest wrote:
| If using the tool effectively is burdensome enough, then
| it's the same as "dealing with it".
| empyrrhicist wrote:
| 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.
| noufalibrahim wrote:
| 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.
| [deleted]
| atuladhar wrote:
| I'm sure this was a typo, but I don't think you meant
| "condemned." Maybe "commended"?
| dieselgate wrote:
| 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
| Cyphase wrote:
| Refreshed before I commented to say this and saw your
| comment labelled "0 minutes ago". :)
| noufalibrahim wrote:
| Commended. Yes. Stupid autocomplete on the phone.
| joshmanders wrote:
| > [...] great achievement and something to be condemned
|
| I assume you mean "not condemned" or "commended" possibly?
| euroderf wrote:
| There's also "condoned".
| hdjjhhvvhga wrote:
| You remind me of my primary school teacher who had the
| tendency of condemning me for my achievements...
| noufalibrahim wrote:
| Great art is often unrecognised by people stuck in the rut
| of convention.
| [deleted]
| tharkun__ wrote:
| 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.
|
| Prompt me, sure. Disallow? WTF?
|
| 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.
| actionfromafar wrote:
| xkcd://1172
| throwbadubadu wrote:
| Yes, and voiding even more use cases, total deal breaker,
| leave that to your or remote's githooks if you need it.
| adql wrote:
| > 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.
| michaelmior wrote:
| 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.
| stronglikedan wrote:
| 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.
| dahart wrote:
| 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.
| jonfw wrote:
| 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.
| zikduruqe wrote:
| That's what tig is for.
|
| https://jonas.github.io/tig/
| qez2 wrote:
| [dead]
| prepend wrote:
| 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.
| nicoburns wrote:
| 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.
| zztop44 wrote:
| 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.
| julien040 wrote:
| 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
| adql wrote:
| Git gud with git or get gut ?
| chriswalz wrote:
| This looks very similar to bit CLI -
| https://github.com/chriswalz/bit
| julien040 wrote:
| 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
| JustSomeNobody wrote:
| 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.
| lamontcg wrote:
| > 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.
| rendall wrote:
| 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.
| ocimbote wrote:
| 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)
| psygn89 wrote:
| I like the sensible names. It would have made it more easier to
| grasp the basics and recallable.
| relyks wrote:
| There is a similar project, Gitless: https://gitless.com/ A
| maintained fork is here: https://github.com/goldstar611/gitless
| (I use it)
| julien040 wrote:
| A great deal of inspiration comes from GitLess; it is an
| excellent project.
|
| It's cool to see a fork of it.
| martinvonz wrote:
| Other similar projects are https://github.com/arxanas/git-
| branchless and https://github.com/martinvonz/jj.
| 5evOX5hTZ9mYa9E wrote:
| 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.
| psd1 wrote:
| 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.
| pech0rin wrote:
| 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
| eviks wrote:
| User-friendly Git CLI is GUI
| revscat wrote:
| Think something may be off on iPhone rendering. Your accordions
| don't look quite right, I think:
|
| https://i.imgur.com/9mGrHpi.jpg
| julien040 wrote:
| 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.
| ravenstine wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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.
| julien040 wrote:
| 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
| yjftsjthsd-h wrote:
| > 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.
| julien040 wrote:
| Yes, it asks if telemetry can be enabled.
|
| Here is how it looks: https://cln.sh/rCmVtVhZ
| bin_bash wrote:
| 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.
| systems wrote:
| 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)
| mdgrech23 wrote:
| 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.
| thfuran wrote:
| 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.
| iudqnolq wrote:
| 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.
| IshKebab wrote:
| 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.
| stef25 wrote:
| > Git alternative command line interfaces just make no sense
|
| Couldn't you say the same for wrappers around an API ?
| systems wrote:
| 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
| Nezteb wrote:
| 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!
| quijoteuniv wrote:
| Awesome! And you probably learn the GIT commands in the meantime.
| Good job sharing too!
| phailhaus wrote:
| 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!
| nextlevelwizard wrote:
| Just learn to use git.
| gigatexal wrote:
| 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.
| BlackLotus89 wrote:
| 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
| mr_mitm wrote:
| 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.
| julien040 wrote:
| 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.
| BlackLotus89 wrote:
| 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
| replwoacause wrote:
| 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.
| julien040 wrote:
| Thank you !
| tambourine_man wrote:
| 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
| 1vuio0pswjnm7 wrote:
| 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.
| julien040 wrote:
| 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.
| dcow wrote:
| 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.
| kmarc wrote:
| 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!
| iraldir wrote:
| 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.
| julien040 wrote:
| It's nice. Thanks!
| ainar-g wrote:
| 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/
| maxloh wrote:
| 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/
| julien040 wrote:
| Thanks for suggesting this.
|
| I've opened a new discussion on GitHub about this feature:
| https://github.com/julien040/gut/discussions/38
| dutzi wrote:
| Lovely website!
| user- wrote:
| 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.
| fsckboy wrote:
| what do you question, legitimately curious?
| dahart wrote:
| 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.
| hn_20591249 wrote:
| 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.
| renewiltord wrote:
| 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.
| mynameisvlad wrote:
| > 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.
| kerblang wrote:
| 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.
| dutzi wrote:
| Lovely website <3
| 0xbadcafebee wrote:
| 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...
| NayamAmarshe wrote:
| Simple and nice webpage design and cool tool as well :D Well
| done!
| airstrike wrote:
| 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
| julien040 wrote:
| Thank you for the suggestion.
|
| I'm adding `gut stash` to the next command to implement.
| kickette wrote:
| Is git a problem that needs solving? It's not that difficult to
| learn/lookup commands.
| tptacek wrote:
| 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.
| nrvn wrote:
| 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
| julien040 wrote:
| > 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
| lampshades wrote:
| You know another easy-to-use CLI for Git? Git.
| KingMob wrote:
| You think so? I can't think of many other interfaces that have
| a site like https://ohshitgit.com dedicated to them.
| gareth5851 wrote:
| mercurial was essentially a more intuitive version of git. too
| bad it wasn't more widely supported.
| phailhaus wrote:
| 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.
| mhalle wrote:
| 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.
| memco wrote:
| > 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.
| julien040 wrote:
| 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.
| julien040 wrote:
| 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.
| L3viathan wrote:
| 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.
| meremortals wrote:
| I think this is great. Well done
| 8organicbits wrote:
| 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.
| julien040 wrote:
| 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.
| danenania wrote:
| 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
| 8organicbits wrote:
| There's some open source tools that attempt to help, but
| yeah, it's a hard problem.
|
| https://github.com/topics/secrets-detection
| nidnogg wrote:
| 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!
| julien040 wrote:
| 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
| wadadadad wrote:
| 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.
| julien040 wrote:
| I've added this to the docs. Thank you for pointing this
| out
| 12345hn6789 wrote:
| There already is an easy to use cli for git. It's called `git`
| pil0u wrote:
| 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.
| julien040 wrote:
| 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.
| johnea wrote:
| I thought git was the CLI for git?
| eddywebs wrote:
| Ohh nice ! commandline for a commandline.
| agumonkey wrote:
| It's quite cool. That said, I wonder why git doesn't leverage
| those porcelain to improve itself.
| ar9av wrote:
| 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.
| julien040 wrote:
| 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.
| [deleted]
| codetrotter wrote:
| > 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.
| julien040 wrote:
| I hope the moderation is aware. I don't know HN very well.
| Is there a way to warn them of the problem?
| codetrotter wrote:
| 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".
| JasonFruit wrote:
| 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.
| codetrotter wrote:
| > 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.
| tptacek wrote:
| I read this as "every command leaves your repository in a state
| where you can finish your tasks using the standard git
| command".
___________________________________________________________________
(page generated 2023-03-30 23:01 UTC)