1M Lazygit downloads, one embarrassment at a time | Hacker News Reader

1M Lazygit downloads, one embarrassment at a time

jesseduffield.com

67 pointsjesseduffield12 comments

That was awesome. I've been working on a budgeting app and recently demoed it to my in-laws, and I definitely felt quite embarrassed as I was showing it and explaining it. I felt a bit discouraged after but this article has helped me realize that maybe I'm on the right path. Thanks!

Just love lazygit, makes me happy every time I use it, which is every like every 5 minutes. Love how extensible it is with custom actions. Love the recent integration of update-refs. Thank you, happy new job and congrats !

I didn't know about Lazygit and this blog post offers no context nor link to a presentation of the project.

For those like me: Lazygit is a "simple terminal UI for git commands" and is located at https://github.com/jesseduffield/lazygit

Good point. I've updated the post to provide context + link

LazyGit is one of my favorite pieces of software. I use it everyday, I love how seamlessly it fits into my work flow. The fact that it outputs all of its commands has helped me form a deeper understanding of git and what it’s doing under the hood. Not to mention it saves a TON of time.

> Not to mention it saves a TON of time.

Depends on your workflow. I looked at the projects GitHub and I'm confused where the lazy part comes from. The UX seems more complex than just plain git which is much simpler for me. But I rarely do anything other than checkout, add, commit and rebase. And most of them are aliased co for checkout, ci for commit, etc and the rest are tab completed. Starting a TUI and navigating menus would be a waste of time for me.

Here is one thing: I work on a feature branch off of main. It takes me a bit and I want to rebase my branch onto the newest changes.

It seems with the git command line the way to do it is to switch to main then pull then switch back to my feature branch then rebase.

With lazygit i hit f on the main branch which pulls its changes then i can rebase (r) right away.

I also like to review the diff of each file before staging it. I get a nice list of changed files, i can select one and see the diff in it, then I can stage it.

> It seems with the git command line the way to do it is to switch to main then pull then switch back to my feature branch then rebase.

In case you haven't figured it out yet, you can do `git fetch origin` to fetch the latest branches from origin. And then `git rebase origin/main` to rebase the current branch against origin/main. origin/main doesn't have to be the same as local `main` so you don't need to switch branches at all.

It is workflow dependent for sure. I used to use aliased commands (still do sometimes), but I find that the muscle memory of lg (opens lazygit tui) -> a (git add -A) -> c (git commit -m "..." -> enter to be easier for me than typing each alias out. I like the lack of nested menus, everything is available via the top layer of the tui and most command are a single hotkey away.

Funnily enough, I just switched to helix so I needed a git client.

I tried lazygit but couldn't get into it. It was nice but slow for my work's monorepo.

I switched to gitui, which is kinda... Obtuse. But fast. I

I just added a PR to help with fixup workflows. Which is the first time I've contributed to a rust codebase

I really like lazygit when I need something quicker and more ergonomic than the VSCode git extension.

I’m still partial to magit over everything else but lazygit has replaced a lot of my CLI usage of git. Thanks Jesse.

This captures how we "mature" as developers (and humans) when we ship software that other people actually use. A hilly journey of embarassment and pride :)

Thanks for sharing.

Reply on news.ycombinator.com