[worksonmine]

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

[hibbelig]

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.

[johntash]

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

[poetril]

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.