💾 Archived View for dioskouroi.xyz › thread › 29394162 captured on 2021-12-03 at 14:04:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
➡️ Next capture (2021-12-04)
-=-=-=-=-=-=-
________________________________________________________________________________
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
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
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
May I ask what made you choose lazygit instead of fugitive? I'm using the latter and am quite happy with it, but I'm keen to learn what I'm missing out on.
I use both, though I only use fugitive for "git blame" and I use Lazygit for log browsing and partial staging. With me, it's just what tool will stick, fugitive might be great but I just don't stick with it.
Same with editors, I really want to like VS Code but in the end I just open vim by default again.
Same here. Fugitive for me is really only good at git blame and git diff. Rebasing, branching, stashing, commiting is better done with lazygit
You can try vim emulation inside vscode, there is an extension for that.
https://marketplace.visualstudio.com/items?itemName=vscodevi...
I do use that, and it's OK, but I just can't get used to the VS Code workflow or something...
It does not support all vims features.
there's also this:
https://github.com/asvetliakov/vscode-neovim
What is a vim emulator?
An editor extension that makes the editor behave like vim as far as editing operations are concerned (so modal, etc). E.g. Emacs has very accurate vim emulation in evil-mode.
Personally I’m not a fan of the fugitive/magit style UI, ie learn a bunch of esoteric commands (:Git blah) so that you don’t need to remember the other set of original commands.
With lazygit/tig, at least there is a visual pager with shortcut letter I need to press along with a text hint about what it actually does.
Magit is fairly straight forward if you have helm. magit-commt, magit-push, magit-pull, magit-status, etc. But so long as you have helm, it is really easy. A lot of the time I don't even need to type 'magit-', I can just type 'status' and helm will pull 'magit-status' to the top of the list.
> ie learn a bunch of esoteric commands (:Git blah) so that you don’t need to remember the other set of original commands
I use fugitive, but haven't remembered these commands. I map what they do to shortcuts of my choosing e.g. \gad = git add; \gco = git commit; \gpus = git push etc.
Wow, thanks … lazydocker looks really great
Rant time: You've heard it before, git is powerful, but what good is that power when everything is so damn hard to do? Interactive rebasing requires you to edit a goddamn TODO file in your editor? Are you kidding me? To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?! Sometimes you get asked to stash your changes when switching branches only to realise that after you switch and unstash that there weren't even any conflicts and it would have been fine to just checkout the branch directly? YOU HAVE GOT TO BE KIDDING ME!
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, lazygit might be for you.
I sympathise, _deeply_. If you've never found yourself counting lines - repeatedly, because your last attempt failed - while manually editing a hunk, then I envy you.
This is the main reason I use "git gui". When I tell people they tend to have the kneejerk reaction "eww you use a gui with git, learn the command line its more powerful and not that hard".
But being able to right-click individual lines of code to stage/unstage them is basically the only thing I use it for, since editing patch files is a pain. The tool is also very lightweight and opens instantly, which would be a reason to switch to something else if it weren't the case.
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.
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.
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.
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.
I always read these "make git easy" threads and I've also written my own "make git easy" wrapper around git. But this comment is the first that has ever given me confidence in actually trying one (by someone else). Nice job.
What a great idea! Improved confidence + faster learning in a single feature.
>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.
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.
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
Fork is fantastic, plus it’s nice to have a piece of quality software that doesn’t require a subscription. That said, if they released a new major version I would likely pay for it because I’ve been very happy.
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).
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.
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.
I use Fork for picking apart which lines I want to commit. It's very cumbersome to commit only specific files and lines using the terminal.
I use the terminal for everything else. I would _never_ trust a GUI to do a rebase, not even sure if it's possible with Fork because I've never tried.
It definitely is, and the UX is quite lovely :)
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.
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.
I cannot imagine using git and having a reason to commit only half a file. I've known it was possible for several years. But never once has it been a solution to any problem I've had. I suppose we both have limited imaginations.
I know this is covering a mistake, but I've occasionally done one thing, then done a separate thing without committing (especially easy to do with things like one-line version bumps or super trivial bug fixes), then used git commit -p to commit+push the first change while still working on the second change locally. Obviously this only comes up because I suck at task management, but it is a real-life time when the feature is helpful.
It might be because of the UX around it if you're in the terminal? When it's easy to do you you're more likely to advantage of it.
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.
> committing an abitrary range of characters
Honest question: what is the practical use case for this? I'm a fan of small, atomic commits but I don't recall ever wanting to commit just a range of characters.
It could be useful for changes in CSV files or text files with table-like formatting where you want to commit the change in just one specific column of a row, but not the other. I could also see it for binary files which aren't structured into lines.
I use it quite a lot to stage a subset of a change, and then drop the rest of it. In that sense, it's like an overpowered undo tool that helps me keep a change I want without having to rewrite the whole thing.
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.
`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.
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/
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.
>To stage part of a file you need to use a command line program to step through each hunk and if a hunk can't be split down any further but contains code you don't want to stage, you have to edit an arcane patch file by hand? Are you KIDDING me?!
I repeatedly run into this using the interactive features.
I very much agree to this. I almost always use “git add -p”.
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.
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
I may be in between the GUI and CLI camps. I actually use git via a TUI (text user interface) by using vim to either read from or write to git commands.
I can stage hunks by yanking the diff header (excluding the line that starts with @@) and pasting it above the hunk I want to stage and then filtering the hunk through:
:'<,'> !git apply --cached -
If I want to unstage it, I can press u to restore the hunk I just filtered and then run
:'<,'> !git apply -R --cached -
I can commit from within vim by reading the verbose status output by running:
:r !git status -v
typing my commit message at the top and filtering it through
:'<,'> !git commit -F -
> 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.
In addition to what I wrote above using git apply --cached, I can actually edit hunks from within vim and then filter the hunk (with the diff header) through the recountdiff utility that comes with patchutils. That basically updates the numbers in the line that starts with @@ to account for the changes in the number of added and removed lines introduced by the edit. This way, I can stage my changes and still exclude extraneous changes or debug statements I've added to the code.
I've actually found this to be a better experience compared to using the -p option.
I agree with you, but it does feel strange whenever I do dip into IDEs which have thousands of features built-in to keep you inside the IDE but to then revert back to the command-line to do git stuff. I can imagine for someone who typically uses an IDE, especially if they work on Windows or OSX it would be even weirder.
> _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…
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.
IntelliJ allows partial commits really well. Use it all the time. SmartGit also does the same. One problem with intellij UI is that it doesn't let you 'uncheck' line ending change from being staged like it does for individual changes in a file.
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.
not quite a "GUI", but lets not forget about vim-fugitive which does all this and a lot more besides.
Gitkraken has an undo button :)
I know this is going to sound elitist, but it always bothers me to see comments like this that make it seem like it's okay to not learn how computers work even though you're a software developer (which I'm assuming you are).
The command line isn't some mystical scary thing, it's a extremely effective method of controlling a computer. It's survived this long for a reason, and it's not going to go anywhere. It's powerful, and extremely simple. _Children_ learn how to use it every day (nerdy children, but still).
Try spending a few hours over the weekend actually trying to learn it. If you do, you'll see how it's a lot easier than you thought, and saying that you're "terrified" of it is silly.
I think most of the aversion towards the terminal comes from how easy it is to screw up things with it as well. There are hundreds of horror stories where one missing "-" or some other character ended up nuking people's entire works and databases worth many hours. Having a GUI gives a buffer and dramatically lowers the chances of doing things that you didn't intend to do.
Another aspect of this is that people will never really learn Git with a GUI and all these aliased commands. I'm not against aliases and I use them, but only on software that I'm very familiar with. Developers who are afraid of Git need to sit down and read _Pro Git_ and learn the most commonly used commands, and use a quality reference for the more obscure ones.
> extremely simple
For some things, definitely not for doing a 3 way merge.
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.
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.
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.
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.
edit: i'm just scratching the surface on what magit can do... literally everything is possible through the interface even one off git commands but almost everything is very easy and interactive from any point in the interface
Honestly... I'm the exact opposite. It's impossible to craft a complex GUI intuitively I think.
Apparently it was also impossible to craft a complex CLI intuitively.
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. :)
Usually, I feel like git is more than enough. But when I have my push rejected because I failed to fetch first, it's just a single click in IntelliJ to fetch, rebase my work on that and push it again.
There's also hub, from GitHub. I find myself using "hub sync" to update all my local branches at once.
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.
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.
This has the same vibe as cooking a piece of beef until it's shoe leather
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.
> a GUI can be excellent and better than CLI
A unicycle can also be better than a car. Doesn't mean anyone should ever choose a unicycle over a car (unless you're a clown I guess)
If you prefer imagemagick to photoshop.
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
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.
> ammend = commit --amend # I cannot spell this word for the life of me
This reminds me of one of my favorite silly aliases, which requires declarations in both my shell profile and my .gitconfig:
In .bashrc :
`alias gits=git`
In .gitconfig :
`[alias]`
`tatus = status`
This allows me to mistype `git status` as `gits tatus` and brings me a small amount of joy.
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!
ohmyzsh has git plugin and a few other git-related plugins with these aliases already available
https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/git/R...
I used to use aliases but got frustrated with them when dealing with PRs depending on PRs, so I wrote git-stack [0]. Thought I'd share in case you'd find it useful
[0]
https://github.com/epage/git-stack/blob/main/docs/reference....
consider:
[pull]
rebase = true # if you're going to do it anyway might as well make it the default
[rebase]
autoSquash = true # if you use --fixup commits
autoStash = true # save yourself the roundtrip
Magit is another popular alternative for emacs
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.
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
)
The edamagit extension for VS Code is also fairly good:
https://marketplace.visualstudio.com/items?itemName=kahole.m...
Another great terminal UI for git is tig:
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.
i've been using [gitui](
https://github.com/extrawurst/gitui
) for that. lazygit does seem like it has more features though
I use tig exclusively to stage commits. Alias tigs='tig status' lets me select / discard lines.
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.
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.
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
)...
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.
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...
Good call. Thanks!
So download a binary instead of building it from source?
Came here to whine, got a what seems in retrospect to be a perfectly obvious and simple _solution_. Thank you!
Jesse you're leaking email addresses in your interactive rebasing example animated gif.
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.
Was hoping lazy git would perhaps help with a feature that tig lacks and I've only found via vim-fugitive. I.e. viewing the whole file between revisions
https://s.natalian.org/2021-12-01/git-file.mp4
IntelliJ's git view can do this too. You can select a file, view its complete history, and view a diff between any two revisions, as well as see the complete state at any revision. And the commit messages are in a subframe.
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?
I guess Emacs is a sort of UI framework, considering Magit.
Am I missing something with Ubuntu? Is it really deprecated? What’s the best way to install and keep up to date on Ubuntu?
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.
That's bad practice though. Devs should be comfortable having older (security patched) versions of software in repos, which provide a valuable service for users.
It's hostile for devs to push PPAs only, as it implies that their ability to push updates faster is more important than the distro's review process.
Linus Torvalds about this:
https://www.youtube.com/watch?v=Pzl1B7nB9Kc
Distros (Debian in particular comes to mind) have some really annoying packaging rules, and as a maintainer of a Go program, it's a huge pain, so we decided to just set up a repo with
instead of trying to deal with that. They require every dependency (indirect or not) to be packaged separately. We don't have the time for that. Way simpler to just build a static binary and ship it.
Take the nix pill
I tried Lazygit and didn't like it. But my git needs are pretty simple, since I use it for text, not code, and rarely do more than commit, push and pull (with the occasional branch), so clients built into editors or the CLI are good enough for me.
Can lazygit help me clean up my branches?
Our GitHub is set to delete a branch whenever we squash merge it in a PR. But for the life of me I cannot get my local version to cleanup too. All the stack overflow popular answers that use sed and such fail for some reason.
git-flow has worked well in this regard for me.
git remote prune origin ?
git trim?
If you meant this:
https://github.com/foriequal0/git-trim
Thank you! Didn't know about it and it solves the problem I'm having.
I don't care how lame it makes me...I love my GitHub Desktop app. I will give this a go!
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.
I tried (just like I tried a whole bunch of other things). I get this both in `cmd` and in `ConEmu` on Windows 10 Pro-64 bit (Version 10.0.19043.1387). After the crash, all the enhanced console functionality is gone.
panic: '%' is not recognized as an internal or external command, operable program or batch file.
goroutine 39 [running]:
github.com/jesseduffield/lazygit/pkg/commands.(*BranchListBuilder).obtainBranches(0xc00039bef0, 0x1367340, 0x10000, 0x0)
/home/runner/work/lazygit/lazygit/pkg/commands/loading_branches.go:43 +0x693
github.com/jesseduffield/lazygit/pkg/commands.(*BranchListBuilder).Build(0xc0000dbef0, 0x11315f7, 0xc0000a4690, 0x1326e87)
/home/runner/work/lazygit/lazygit/pkg/commands/loading_branches.go:103 +0x52
github.com/jesseduffield/lazygit/pkg/gui.(*Gui).refreshBranches(0xc0000b8000)
/home/runner/work/lazygit/lazygit/pkg/gui/branches_panel.go:69 +0xc6
github.com/jesseduffield/lazygit/pkg/gui.(*Gui).refreshReflogCommitsConsideringStartup.func1()
/home/runner/work/lazygit/lazygit/pkg/gui/commits_panel.go:69 +0x45
github.com/jesseduffield/lazygit/pkg/utils.Safe.func1(0xb35af5, 0xc000055da0)
/home/runner/work/lazygit/lazygit/pkg/utils/utils.go:95 +0x2b
github.com/jesseduffield/lazygit/pkg/utils.SafeWithError(0xc00039bfb8, 0x0, 0x0)
/home/runner/work/lazygit/lazygit/pkg/utils/utils.go:106 +0x67
github.com/jesseduffield/lazygit/pkg/utils.Safe(0xc00008aa40)
/home/runner/work/lazygit/lazygit/pkg/utils/utils.go:95 +0x50
created by github.com/jesseduffield/lazygit/pkg/gui.(*Gui).refreshReflogCommitsConsideringStartup
/home/runner/work/lazygit/lazygit/pkg/gui/commits_panel.go:67 +0xa9
Before the crash, the UI is drawn reaaaaallyyy slowly (my cmd window is 170 characters wide -- maybe that's why)
In any case, I prefer to stick with the command-line.
Thanks for adding the stack trace. I've made a bug issue to track this
https://github.com/jesseduffield/lazygit/issues/1601
and I'll take a look into it tonight. I'll need to dig into why our windows integration tests don't catch this (it appears to be a windows-specific problem)
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.
I fail to see the use of tools like this. Either I use the GUI in my editor, vscode which is decent, or vim or emacs, or I don't (need to resolve conflicts) use a separate program and just do it with the git command.
I've been a huge fan of lazygit. You can even do side-by-side diffing if you combine it with the "delta" pager.
For me, it feels really similar to "gitx", which was mac only and stopped being maintained. Having it just be in my terminal is a bonus.
The main feature missing from any git tool I have used is the Magic Wand that exists in CLion or other IntelliJ tools. I don't understand why that isn't almost a git builtin. Rebasing without magic wand is a massive chore.
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"
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.
If you use windows, I recommend jumping on ZTree Win.
It's a port of xtree gold that works on modern windows. I've been using it daily for probably a decade.
Ah I'm a macOS user, but good to note nonetheless!
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?
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.
Glad you're thinking about this. It was the first "bump" I hit as a new user.
I found that ] and [ cycle through Local Branches, Remotes and Tags.
I recently grew fond of Gitfox. Has been using it for couple months and am very happy with it. Prior to that I couldn't stand any Git GUI and was living in terminal.
If I'm already using an xterm, why would I use lazygit?
It seems to me to be a solution in search of a problem.
It looks to be nice but it merely adds an extra level of complexity.
Thank You !
Going to install this tonight, does it work well with LFS?
I was hoping for an interactive CLI ui kind of like fdisk menu style.. i.e. commands are visible at all times.
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.
I've been using this to great effect for a very long tine! I can only recommend it.
use it all day for all my development work, really cool to see it on the front page :)
The first git command to be taught to beginners should be reflog.
its nice but I prefer tig