Comment by _virtu
2 months ago
The commit workflow was what kept me locked in to the ecosystem for so long. LazyGit was so good that it convinced me I didn’t need JetBrains anymore. If you love the workflow with JB for commits check out LazyGit. It’s a TUI so you can use it in any editor without much friction.
I'm kinda reading this with disbelief. Are there people whose primary use case for IDE is... git gui?
I do almost everything git manually at the CLI. But the Jetbrains IDEs have a fantastic GUI git merge tool, and I also like the local git diff UI. Add in integrated blame mode, ability to pull up version-diff files, and that sort of thing.
It's not part of my daily driver toolbox, but they do get used a lot by me.
You made me realize that I actually do use it, since I often look at git blame and the past changes.
And I like the (recent?) update in which the changes from current commit (not only stage) are coloured.
2 replies →
Merge is about the only time I look for gui experience with git. I'm by no means an expert at git.
2 replies →
Remember this when you're thinking about the average commenter's opinion on anything technical.
Remember what? That people have different preferences, workflows and methods of staying productive?
Someone voiced that they liked a certain tool for a certain feature and suddenly we are judging them for it? I like that people share their thoughts and opinions.
Remember this type of comment. Never let yourself fall into this type of thinking when trying to understand what your users want.
Instead of passing judgement on why someone values something, why not ask?
For example, if you were to ask me why I chose to keep using an IDE that I had spent years of my life building muscle memory using perhaps you would get a better understanding of the specific part of the lifecycle I was at when paying for software.
It's not that the git gui was the reason why I signed up for the software in the first place. The git gui was the last reason for me to not jump ship when switching to something like neovim or helix. This was during a time where LSP was becoming popular so refactoring tools and intellisense were finally getting better adoption outside of the JetBrains tooling. Most of this was achievable with editor du jour + lsp plugins, but the git ui was the one piece I hadn't personally solved outside of the JetBrains ecosystem.
If using the git command line makes you feel like a better developer than me that's fine ;)
Jetbrains' implementation is (was?) just that good, yes (combined with local history).
I think you're thinking about git as a separate thing from the IDE.
I love using IJ + git because there are no seams in between edit and commit. For instance, with IJ, I could easily split every other line of a change into separate commits.
Maybe there's a way in git to stage only certain parts of a diff, but I'd have to go an learn another flag or command that I'm going to forget by the next time I need to do it again.
Also with IJ, I just glance at my main branch tab and the highlighting tells me what commits aren't in my checked out feature branch.
Two small examples but there are many more and it adds up.
git add -i is the thing you'd have to learn.
I do that at the CLI most of the time and I'd say I'm quite experienced with it, but I still prefer IntelliJ when it gets complicated.
1 reply →
That's not the only reason I was using the tooling at the time. Specifically everything else regarding the JetBrains ecosystem kept me hooked, but when I was looking to replace what I liked in JetBrains with other tooling the last piece of the puzzle was replacing the git workflow.
I've been using their git diff/checkin tools built into RubyMine since I started with git. Going on about 12-13 years now. Their conflict resolution UI is so much easier than editing text contents between the >>>>s and <<<<s.
To be fair, VS Code git implementation is really off-putting if you've used something good.
Personally I love it and find it very intuitive.
It allows you to do stuff so much faster than having to type everything manually into the terminal. Also really enjoy the "Undo Last Commit" feature and how I can easily see all modified files at once and shuffle around stuff between the staging area.
1 reply →
I have no idea about both. I just use git in terminal.
Honestly, the git implementation in PyCharm is better than any git app I've used, including lazygit (which I like and is my go-to when not in PyCharm).
Git is just that bad, huh? The best backhanded endorsement of mercurial I've seen so far.
I've always had the opinion that people complaining about it are just holding it wrong.
Or if you prefer a GUI (still separate app, so works anywhere, too): https://git-cola.github.io/
Graphical interface won't work well inside WSL, that's why I dropped my subscription on GitKraken and start using lazygit. lazygit simply works in almost any environment, and it works extremely well even if you are not into terminal stuff.
Yeah, that’s the power of TUI. I would probably give it a go, too, but Git Cola works for me on Linux and Mac without too many issues.
(By “works anywhere”, I meant you can use it with any IDE or editor, or just run it from terminal, though it is cross-platform and should work on Windows, just not sure how well it would play with WSL.)
5 replies →
Really? While there its certainly slightly annoying because they have the "double menu bar" if they use a non-standard one like the jetbrains ides do... I feel like wsl gui support has essentially become a "solved issue" for a while now.
3 replies →
Just found LazyGit as well. it's amazing!
Also like Sublime Merge, if you want a GUI (paid though)
Fortunately JB broke that addiction for my by first moving the commit dialog behind an option, and then removing it completely. If I have to learn a new workfrow, I might as well learn a new tool
Currently the plugin version still works but they made it clear it will be unmaintained in the future.