The rule of 100 states that if you spend 100 hours in a year, which is 18 minutes a day in any discipline, touch-typing, coding, climbing, whatever, you'll be better than 95% of the world in that discipline. You can go and practice your kid's skills for 18 minutes a day, but there's a shortcut that doesn't only get you there faster, it also does most of the work for you. So how do you stay ahead of 95% of everyone else? Ever found yourself fighting an interactive rebase session, felt like banging your head into a wall when fixing conflicts, or how about this feeling of brain cells, literally losing connection when you try to stage a line and find out five more functions are staged with it. Git is powerful, but what good is that power when everything is so damn hard to do? This is a quote that comes from a tool that I love, but wasn't paying enough attention until recently. Most of my basic get-ups are running through fugitive, linked to the video is up here if you're interested. If you're a mere mortal like me, and you're tired of hearing how powerful Git is, when in your daily life it's a powerful pain in your ass, lazy git might be for you. So let's talk about fugitive, and at the end of the video I'll show you how to combine both into a system that will get you superpowers. In case you're unfamiliar with it, fugitive is tip-ups, them git integration that brings almost all git operations to your IDE with bindings. You open the status, stage or unstaged entire files, view the summary of commits that you're staged or un-pushed, etc. No need for external software or CLI. You can also stage individual hunks from within your editor. However, this is where it folds short. The hunks are decided for you. It'll grab a group of changes, whereas if you want specific lines, that's something that git or fugitive doesn't do for you, at least not easily, and will come back to that. Once my changes are staged, committing them and pushing them are all easy actions done from within VIMM, so that after a short while doing them, plus viewing the status and making changes becomes second nature or muscle memory, if you will, something I don't have to spend any energy thinking about. But what happens if you need to do something a little bit more complicated, or would just like to use an actual UI? This is where lazy git comes in. Installation is as easy as any other binary. Use brew, or snap, or just grab the binary from the repo. When I fire it up, un-greeted with a UI with multiple sections, easy to understand and navigate. Navigation is as smooth as using your arrows, or better yet, VIMM, up and down, move internally in the focused list, and with left and right, the focus shifts to the next or previous menu. You can also use tab and shift tab exactly for that. One additional important motion is zooming in and out. That's also an incremental action, and it's a cyclic operation, so you can zoom in all the way and keep going further, that will just cycle back to the original layout and save you from unwanted motions, quitting the thing and coming back. This is done with plus and minus. Remember earlier, how I staged a hunk using fugitive and got the entire section staged? Well, sometimes you may want to add a single line. With lazy git, just hit space on the line you want and watch a jump to the staging area it works backwards just as easily. Hit space again on the sage changes window to pop it back to the unstaged area. There's also an indication in the file section to the left showing either an unstaged, partially changed or fully staged file next to its name. This is specifically helpful when reviewing changes and looking for unstaged bits of code that may be relevant to the current commit. Interactive rebasing is one of the most unpleasant experiences git can offer, and this is another area where lazy git shines. Hit E to start a rebase on a certain commit, then use S to squash, F for fix up, D to drop, and E to edit. M will bring up the rebase options menu to continue or abort the operation. And by the way, another cool feature for those of you who likes squashing commits regularly, it works just as a one-off, so by standing on a commit and pressing S, it'll be squashed without an interactive session. To explore a certain commit, just hit enter and get a menu of changed files which are easily navigatable with the preview window presenting changes made. At any point, hit the question mark operator to open the key bindings menu, which you can filter using the slash operator. Just like in VIM, so for example, if I'd like to reset my changes, instead of remembering syntax or making mistakes, G opens the recent menu, which I can then reset soft, or hard, or mix. Every menu is self-explanatory with bindings showing alongside every operation. This resembles a little lot if you use it, and I love the design that always has the user experience in the center, something that's hard to say about git generally. If you want to cherry pick a commit, hit C, and then V to paste it on the wanted target. How genius is that? Just copy pasting commits. Every operation also has its own self-explanatory confirmation window, so you can understand what's going on, approve operations, or cancel them. The same goes for bisect. If you're unfamiliar with git bisect, this is one of the nicest ways to figure out which commit introduced a bug. By marking commits either as good or as bad. The manual process that git offers in the CLI becomes visual here. If I'm honest, git bisect was never a pain for me anyway, but if I'm already using an interface for all things git, it better have the option. So here I can, again, check in the process whether a commit is good, or gone bad, and throughout the process once git identifies the commit that's gone wrong, it reports that, and then we can fix the bug. Similar to the CLI, it says the bisect is complete and points out where it was introduced. When the changes are finally ready, it's time to commit and push them. And as you guessed it, standing on the files in the browser, hitting C to get the commit menu and the title, in the description that most users don't even bother to write. Hitting Enter on the title finalizes the commit, and that's now ready to be pushed with P. Once again, the amazing UX's self-explanatory telling us that tab will toggle the focus, and this is exactly what I expect from UX that helps me simplify processes, exactly like Zellich does. Now I want to take it to something lazy git can do well, but I prefer another method. Worktrace is my favorite way of managing any git repo. This saves me the hassle of stashing changes when needing to move to another branch while coding, and makes my life easier when I want to review diffs in NeoVin. My go-to is the prime agent's plugin for git worktree and them, which also integrates with telescope, and is just such a sweet experience, I won't replace it. Beyond that, it's better to run worktrace within a bare git repo. Don't worry about it if you don't use worktrace at all. That, lazy currently does not support, so it can create worktrace and manage them for you, but I'd stick with telescope and bare repos for this one. Once the worktree is created within lazy git, it's added to the list, which can then be easily toggled and switched. I still prefer the way telescope does this by showing me a preview of the current file across multiple trees, including the option to open as many trees as I want within separated paints. This is not a problem of lazy git, but rather a plus of using something similar within the ID. Another great plus of lazy git is the presentation of the commit tree. This one isn't very impressive, as this is a private site project of mine, so here's a better example from the source itself. It shows beautifully the structure of branches, points of intersection, authors, and commits, and that aside for sunrise. Before we're going to take lazy git one step further in productivity with a small tweak, here's the last simple yet brilliant feature it offers, comparison of commits. Here's the trick, just hit Shift W when you're on a commit and voila, a handy menu pops up. This little gem lets you pick a commit, as your reference point then choose another commit and guess what, you can instantly see how they differ in the main view. Press enter and you'll dive into the files and see exactly what's changed, and if you feel like mixing things up, go ahead and press Shift W again, this will bring back the diff menu where you can flip the diff direction or say goodbye to diff mode. Oh, and if you're done comparing and you want to go back to your visual workflow, just tap escape, as always. And now for my setup. In my mind, every system I pick, everything that gets in or gets out of my workflow is judged by one main parameter. Is this adding friction to my process or is it taking some away, making my mental flow consistent and for longer periods of time? If I want to use lazy git, having to step out of my editor, open another split, or a floating terminal, is a bit of a pain which cuts my train of thought. However, with Tmax, this is a breeze. I just fire up a pop-up with lazy git inside that I can then use and kill when I'm done, right from within the editor. The nice thing about it is that I don't actually have to be in them, but it works anywhere really, as long as I have an active Tmax session, which I always do. For the Zellage folks out there, you can do exactly the same with floating pains. Your case actually is even nicer since these can be moved around and customized, more on Zellage in the video above. Lazy git is fantastic for everyday git actions, but I found that personally, I need to stay in the same environment for most of my tasks, otherwise my ADHD just kicks in. To solve that, I just pop fugitive for everything. The video is right up here, and if you're still feel like V-Motion's art in great nothing to your muscle memory, here's a great method to quickly learn and remember them easily. Thank you for watching.
