[HN Gopher] Lazygit: A simple terminal UI for Git commands
___________________________________________________________________
Lazygit: A simple terminal UI for Git commands
Author : tnorthcutt
Score : 181 points
Date : 2021-11-30 16:49 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| peterhil wrote:
| Impressive, although quite large program!
|
| One suggestion: Use PgUp and Pgdown to scroll a screenful, and
| use arrow keys to scroll one or two lines. Use shift with some
| keys to scroll half screens.
|
| Is there a keyboard shortcut to go into remotes or tags panes?
| jesseduffield wrote:
| Yeah I regret using pgup/pgdown for regular scrolling in the
| beginning. I'm gonna add keybindings for paging up and down
| properly (so that a user can remap those to pgup/pgdown) and I
| think down the line I might change that to be the default
| behaviour, but it's tricky when it comes to keybindings people
| are now familiar with after using the app for a while.
| andrethegiant wrote:
| I guess it takes getting used to, but at first glance, the
| screenshots of lazygit look more complicated to me than git's
| normal stdout.
| acherion wrote:
| This looks great, looking forward to trying it out. I am kind of
| getting X Tree Gold vibes, great to see that the UI colours are
| customisable, I might have a crack at giving this an X Tree Gold
| theme / look.
| vikinghckr wrote:
| Very interesting project! This is one area where I always felt
| git was worse than mercurial. Latter has extremely useful tools
| like `hg hisedit` and `hg split`, for which git didn't have a
| counterpart.
| softwaredoug wrote:
| I maintain a bunch of git aliases in my .gitconfig for my
| company's rebase based workflow. They cover 90% of my 'dumb' git
| usages synced = pull origin master --rebase. #
| Update myself with master squash = rebase -i
| origin/master # Let me optionally squash whatever has happened
| since master publish = push origin HEAD --force-
| with-lease # Save to orig in (github) pub = push
| origin HEAD --force-with-lease # Save to origin (github)
| ammend = commit --amend # I cannot spell this word for the life
| of me amend = commit --amend
| agilob wrote:
| If you use zsh and ohmyzsh you have these commands available in
| `git` plugin with full docs here
| https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/git/R...
|
| A must read for every cli git user.
| dstroot wrote:
| I use Oh My ZSH git aliases. Examples:
|
| gcmsg "git commit -m" - Git commit message
|
| gco "git checkout" - Change branch
|
| gd "git diff" - Files differences in staging
|
| gl "git pull" - Pull from remote
|
| gp "git push" - Push to remote
|
| --- Tool looks interesting!
| agilob wrote:
| ohmyzsh has git plugin and a few other git-related plugins
| with these aliases already available https://github.com/ohmyz
| sh/ohmyzsh/blob/master/plugins/git/R...
| tigerlily wrote:
| Jesse you're leaking email addresses in your interactive rebasing
| example animated gif.
| xaduha wrote:
| If someone wanted to get those emails they could get them from
| git any number of ways, analyzing animated gifs would be
| somewhere near the bottom of that list.
| phist_mcgee wrote:
| Fulltime lazygit user here. Honestly, this program is the best of
| both worlds, a fast keyboard friendly gui, with the ability to
| interact with git as if it were you typing the commands by hand.
|
| Protip: alias lg="lazygit"
| alxndr13 wrote:
| use it all day for all my development work, really cool to see it
| on the front page :)
| throwaway984393 wrote:
| Looks awesome. It almost seems arcane now to write a program that
| is _only_ is designed to make a person 's everyday life simpler
| and easier. I love the idea of programs like this, but then I
| find myself nit-picking over whether I want it to be console,
| graphical, web... There's no such thing as a UI framework that
| works for all three, right?
| avgcorrection wrote:
| I guess Emacs is a sort of UI framework, considering Magit.
| ahurmazda wrote:
| A very satisfied user. As a (neo)vim user, I did suffer from
| magit envy but at the end, Lazygit takes care of all my needs. I
| prefer the UX (Just a personal preference).
|
| Kudos to the dev for the wonderful tool
|
| PS: There is also lazydocker by same person
| https://github.com/jesseduffield/lazydocker
| hanklazard wrote:
| Wow, thanks ... lazydocker looks really great
| the_duke wrote:
| There even is a Neovim plugin which can open lazygit in a
| floating window. The active Neovim instance will be used for
| multiline commit messages.
|
| https://github.com/kdheepak/lazygit.nvim
| ahurmazda wrote:
| Nice.
|
| I have it hooked up to the toggleterm plugin [0]. This way I
| can pop layzgit and other things (gdb, ipython etc) on a
| floating term
|
| [0] https://github.com/akinsho/toggleterm.nvim
| buf wrote:
| I use lazygit a dozen times or more per day. As a tmux+vim user
| w/lazygit, I don't think I've touched my trackpad in years, and
| it still feels like a modern interface and faster than all the
| IDEs out there.
| 999900000999 wrote:
| Thank You !
|
| Going to install this tonight, does it work well with LFS?
| jordanmorgan10 wrote:
| If there is one thing that terrifies me it's using Git, or any
| source control, from the command line. No matter how long I've
| been in this industry, I just can't get cozy with doing a lot of
| heavy lifting in any shell environment. Give me the GUI all day
| every day.
| rackjack wrote:
| This has the same vibe as cooking a piece of beef until it's
| shoe leather
| GhettoComputers wrote:
| It's more like using hamburger helper instead of a spice
| rack, a GUI can be excellent and better than CLI, beef isn't
| always better when it's overcooked.
| agilob wrote:
| Exactly the opposite for me. I absolutely do not trust GUIs to
| do the right thing. I don't trust text area to use correct line
| endings consistently across platforms, I don't trust them to be
| up to date with new options for `commit` or `checkout`, they
| never show examples what result will be (--dry-run). None GUI
| is ever up to date with documentation and contains all
| functionality which I can autocomplete with [tab][tab] in zsh.
|
| Does any GUI offer `-p` in `git commit` and `git stash`? I
| literally use it 10s times per day, can't live without it once
| I started using it.
| eschneider wrote:
| I'm definitely team command-line for git, but I've been
| happily using lazygit to quickly review repo changes before
| committing and it's been pretty good for that.
| dceddia wrote:
| In regards to `-p` -- Lazygit does this. You can press
| Spacebar to stage individual lines and then partially commit
| or stash the staged stuff.
|
| I like it better than git's built-in `-p` because you don't
| have to rely on git chunking things up the way you hoped, or
| spend time splitting git's chunks (hunks?) to get the
| specific line you wanted to stage.
| BoorishBears wrote:
| The entire point of a GUI is you get the behavior of -p and
| --dry-run in a much richer context! I've never seen a GUI
| that _doesn 't_ let you very easily select specific lines for
| commits and I honestly wouldn't use one that didn't.
|
| I cannot imagine using git and only being able to push entire
| files...
|
| -
|
| And for the record, I use Sublime Merge and it does a great
| job mapping to terminal commands.
|
| Hover over any button and you get the exact git command it
| will run. It doesn't mess with your tree directly, every
| action maps to a normal human readable git command.
|
| If you want to make a stash with untracked files for example,
| you just hit the arrow next to "Stash" and get a dropdown
| with command line args and descriptions for what they do.
| Sublime Merge will then run it with the exact args you
| entered, show you the exact CLI command it used, and will
| show you the exact output.
|
| _For me_ Sublime Merge is strictly better than a terminal. I
| 'm comfortable with terminal commands but it's the terminal
| with a very nice diff view, clean graphs, easier text
| editing, etc. I never have any ambiguity about what it's
| going to do.
| ljm wrote:
| I use magit in emacs and I can create any commit I want by
| slicing out a bunch of characters in a diff.
|
| The git CLI is workable for a lot of things,but the
| experience of higlighting an arbitrary block of text and
| saying "commit THIS" has not been matched in any other git
| UI. We're not talking about hunks or lines here, but
| literally committing an abitrary range of characters.
| Groxx wrote:
| Literally every git GUI I've used has screwed up a git
| repository at some point, requiring relatively-advanced CLI
| use to untangle it. They're _wildly_ untrustworthy IMO. They
| also almost never perform reasonably on truly large repos,
| aside from gitk.
|
| Since using a GUI has inevitably required me to learn CLI in
| depth, and adds the complexity of figuring out what the hell
| the GUI actually did because of course it doesn't tell you,
| I'm basically 100% CLI as well.
| stevage wrote:
| I use GitSavvy. It feels the safest to me because I use the
| same small set of actions frequently. I fuck things up on
| the command line much more readily and in ways that I find
| harder to fix.
| agilob wrote:
| >Literally every git GUI I've used has screwed up a git
| repository at some point,
|
| I got burnt by this with svn... when unfucking things was a
| lot more complicated and required faster disk and
| connection.
| drainyard wrote:
| I found this to be true for a long time, but these days you
| have something like Fork which is much lore user friendly
| and FAST! We used to use Sourcetree, which is an
| abomination in comparison.
|
| I always use(d) the terminal, but Fork is the first time I
| am considering using a GUI as my main tool.
|
| Granted I haven't had to do anything complicated yet with
| it, so I don't know if it supports it, but I love it for
| the basic day-to-day tasks that I do 100's of times a week.
| acherion wrote:
| Fork is amazing, paid user here. We used to be on
| SourceTree but found out the hard way that it's a massive
| CPU hog, especially after being open for a long time (at
| least on Mac OS).
| Groxx wrote:
| I'll have to give it a try - I'm not _opposed_ to GUIs, I
| 've just had consistently bad experiences :)
|
| And agreed on Sourcetree. It started out promising, but
| oof. Not any more.
| dmitriid wrote:
| Also, GitUp (don't know the state of development now,
| though). Blazingly fast (but not on big repos with years
| and years of history), almost everything is done via
| keyboard shortcuts, allows scenarios like "oh, just mov
| this commit down, this comit up, squash these two, and
| re-write the commit message" in 5 seconds tops
| jesseduffield wrote:
| One of the largest pieces of feedback I've had is around
| displaying the actual git commands that lazygit runs so now
| there's a new panel that does exactly that, displayed by
| default. I find that works well for demystifying what's
| going on and can actually help educate on which commands
| can satisfy which use cases. It's also kept me accountable
| in that if I try to satisfy some use case in a sneaky,
| smart way, it results in a scary looking series of git
| commands, so I've scaled back some of the 'magical' stuff
| that was going on for the sake of user confidence.
| reificator wrote:
| I was also in this boat, but vscode has been reliable for
| me. Maybe I'm not clicking the wrong options, but I used
| the gut cli exclusively for years so maybe my mental model
| is in the right place to avoid that.
| flohofwoe wrote:
| As far as I have seen (I prefer the cmdline myself) Git UIs
| usually have all sorts of features to select what changes
| should go into what commits down to single text lines. IMHO
| this sort of fine grained 'commit management' would be the
| only reason to use a git UI over what the command line
| offers.
| Groxx wrote:
| `git add -p` does that as well, it's effectively what the
| GUIs are using. You can also [e]dit each thing and rewrite
| as desired, though it can be a bit fiddly.
|
| UIs can be nicer though for rewriting / making finer-
| grained splits than the hunks that -p decides on,
| definitely agreed there. I have broken out a UI _just_ to
| simplify staging some gnarly commits. GUIs are also often
| nicer for understanding and resolving nasty three-way merge
| conflicts.
| Jaxan wrote:
| I very much agree to this. I almost always use "git add
| -p".
| Groxx wrote:
| tbh I think the staging area (and popularizing local
| branches) may be git's greatest contribution. being able
| to _selectively_ build a commit is a game-changer for
| creating understandable histories, and stopping local-
| tweak "leakage".
|
| distributed VCS is neat and all, but the vast, _vast_
| majority of cases have a canonical source-of-truth repo
| somewhere, and the rest are effectively just private
| mirrors. for those cases, distributed is mostly a
| significant source of complexity rather than capability.
| though it is significant to have an "escape hatch" when
| you need it.
| agateau wrote:
| git gui, which comes with git, is quite efficient to do
| partial commits. I wrote an article about this a few
| years ago: https://agateau.com/2016/an-intro-to-git-gui/
| Groxx wrote:
| I haven't actually tried git-gui, only gitk... I'll have
| to give it a try, thanks :) A first-party GUI actually
| gives me some hope for correct behavior. gitk is broadly
| excellent for example and performs great, though other
| GUIs do some things more smoothly - exactly what I'd want
| in a first-party GUI.
| [deleted]
| ossopite wrote:
| yes, and in my experience UIs make this much easier than -p
|
| but for me a bigger reason to prefer a git UI is that I can
| actually see the graph. I can do things like drag branches
| between commit nodes. I find this so much easier and safer
| than the cli
| bradwood wrote:
| not quite a "GUI", but lets not forget about vim-fugitive
| which does all this and a lot more besides.
| reificator wrote:
| > _Does any GUI offer `-p` in `git commit` and `git stash`? I
| literally use it 10s times per day, can 't live without it
| once I started using it._
|
| VSCode's GUI handles most of what I use -p for, though if I
| need to use `s` inside -p I drop to the integrated terminal.
| Not sure if the gui has an equivalent but I haven't noticed
| it.
|
| Stash on the other hand isn't missing anything I care about:
| the gui lets you name stashes if you want, apply latest,
| etc...
| chana_masala wrote:
| That's funny, I'm the exact opposite. An old gray beard pair
| programmed with me at my first development job. He taught me
| Vim and Git CLI. I've never been able to get used to any UI
| over Git. I am way faster and more proficient with the CLI.
| w0m wrote:
| Honestly... I'm the exact opposite. It's impossible to craft a
| complex GUI intuitively I think.
| weaksauce wrote:
| i can firmly say that installing emacs and doom emacs is well
| worth it solely for the magit interface. simply phenomonal.
|
| if you know the bare basics of emacs(like a few file commands
| and how to exit), magit and vim that is a huge productivity
| win. magit is simply the finest complete git gui that does most
| things seamlessly.
|
| simple workflow
|
| in the project dir
|
| $ emacs
|
| spc-g-g to enter magit
|
| ? shows help(and every command pops up a menu with options)
|
| j/k to navigate lines up and down
|
| s and u to stage and unstage chunks of text/files/lines
|
| x to delete something
|
| cc to initiate a commit
|
| edit the commit message
|
| ctrl-c ctrl-c commit.
|
| ctrl-c ctrl-c abort commit
|
| q or escape goes back a "page" like from viewing the log to go
| back to the staging area
|
| the trick is everything follows that basic form where [a-zA-Z]
| starts a command, pops up a menu and shows the next options but
| the general trend is that it usually is the same two letters.
| bb is checkout a branch and it usually pre-populates the thing
| you are on if that is applicable. ll is log this branch. la is
| log all branches and everything in the log is interactive.
|
| it's pretty magical.
| stevage wrote:
| I haven't used that one, but the experience you describe is
| similar to GitSavvy in Sublime. Which is the only reason I
| install sublime these days.
| weaksauce wrote:
| So I just tried it out and it's noticeably more irritating
| than magit on first brush:
|
| doesn't work well with vim plugins... need to go to insert
| mode to actually interact with it (might be configurable
| and fixable)
|
| stuff that takes one keystroke on magit is clunkier in
| gitsavvy. tab in magit expands short diffs from the main
| status page where you can stage or unstage selections or
| get an overview of the changes. l to "inline diff" opens a
| diff in a new file whereas tab just opens and closes
| sections on the main dashboard. ctrl-jk move from chunk to
| chunk. enter opens the file to edit or more generally does
| an action like view the commit under the cursor if you are
| in a the log graph and q will "quit" out and pop the
| interaction back to the log graph.
|
| it's hard to overstate just how well everything flows in
| magit and i've never heard anyone say anything bad about it
| other than something like I wish it wasn't tied to emacs.
| simply the best and most well thought out piece of software
| i've used.
| 908B64B197 wrote:
| The command-line is the gateway to scriptability.
|
| > I just can't get cozy with doing a lot of heavy lifting in
| any shell environment
|
| I've argued that undergrads should spend their first year (or
| first semester) almost exclusively on the terminal/in the
| shell. Sure it makes some operations cumbersome but after you
| get over the learning curve the returns are spectacular.
| nnanda wrote:
| It's totally opposite for me. I can't understand the UI apps
| for GIT. Right now I am using IntelliJ Idea and it has an
| excellent GUI for GIT; however, for all my GIT work, I still go
| to terminal app. :)
| teawrecks wrote:
| I think it's possible to create a git GUI that is superior to
| the cmdline, but I've never seen it. SublimeMerge usually works
| fine, very useful for staging hunks. I still do interactive
| rebase on the cmdline tho.
| thebruce87m wrote:
| Am I missing something with Ubuntu? Is it really deprecated?
| What's the best way to install and keep up to date on Ubuntu?
| ilaksh wrote:
| I think that it's just difficult to submit updates to Ubuntu or
| get them incorporated. I think you can just download the binary
| and put it in /usr/bin or clone and run go install as per the
| instructions.
| not-my-account wrote:
| Lazygit is terrific. I started learning git on the command line,
| and had that pompous opinion that "GUIs are a crutch" - but with
| Lazygit, I am so much faster, doing everything - comiting,
| squashing, rebasing, etc. I can't recommend it enough.
| giglamesh wrote:
| Looks pretty great, but: Error! Your Xcode (13.0)
| is too outdated
|
| I don't have the luxury of upgrading yet. This requirement seems
| overly fussy and opinionated.
| ripley12 wrote:
| So download a binary instead of building it from source?
| Groxx wrote:
| I believe that's coming from homebrew itself, which is pretty
| aggressive about updating everything. The homebrew formula
| contains no reference to xcode version, for example:
| https://github.com/Homebrew/homebrew-core/blob/master/Formul...
| sli wrote:
| Switched from regular terminal use to lazygit shortly after this
| was released and have never looked back. I still do more complex
| git stuff manually, but my usual git workflow is totally covered
| by lazygit.
| tiernano wrote:
| seen the name, had to laugh... I actually own the domain
| lazygit.net... when i bought it, it was more for the idea that
| git is slang (https://en.wikipedia.org/wiki/Git_(slang)), which,
| actually, while reading on Wikipedia, seems one of the reasons
| Linus picked the name
| (https://en.wikipedia.org/wiki/Git#Naming)...
| hyperpallium2 wrote:
| The first git command to be taught to beginners should be reflog.
| jmcphers wrote:
| Another great terminal UI for git is tig:
| https://jonas.github.io/tig/
| aequitas wrote:
| Tig is great for visualising and stepping through history but
| for quickly performing other Git related task I found it was
| missing something. That something turned out to be exactly
| Lazygit.
| Mulderns wrote:
| I use tig exclusively to stage commits. Alias tigs='tig status'
| lets me select / discard lines.
| boojing wrote:
| Magit is another popular alternative for emacs https://magit.vc
|
| I wonder if anyone has gone from lazygit to magit or the other
| way around. As someone who uses emacs for my day to day dev work
| I can't see myself changing.
| pkd wrote:
| Not that I would switch away from Emacs itself, but I can see
| myself using Emacs just for Magit even if I was not using it
| for anything else. Magit is just that good. (Consider
| sponsoring Jonas on Github if you use and love Magit so that he
| can keep making it awesome.
| https://github.com/sponsors/tarsius)
___________________________________________________________________
(page generated 2021-11-30 23:00 UTC)