I think a big problem with Git is that it's not opinionated enough. Every team has their own Git flow because Git makes it possible to do so and most developers love nothing more than micro optimizing every minute aspect of any work that is not the task they've been assigned this sprint (myself included), or avoiding learning anything at all (half of my coworkers) thereby leaving the decisions to people like me. I'd much prefer a tool that has one way to do things and everyone just had to "get with the program." Instead, we have this Swiss Army knife that can do anything but requires arcane knowledge of how to do things that are just slightly off the beaten path.
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
The problem with an optionated tool that mandated a specific workflow is that people that can't follow this workflow can't use the tool
This follows the Unix principle of "provide mechanisms, not policy" (as I remember from the esr book on Unix philosophy - <imagine a link here>). Git provides mechanisms for version control and it's up to users, projects, organisations, etc to set up policy. That's because mechanisms are more universal, and policy changes with the whims of the stakeholders
(I actually agree that tools that mandate a workflow are more enjoyable. Not everyone needs to use the same version control and different DVCSes can or could be interoperable like git and jj are)
Yeah, I think we could use a little more of "not trying to be everything for everyone". If more opinionated tools meant there were five or ten VCSes in common use rather than 1 or 2, I think that would be a better world.
As long as they are interoperable, sure. Otherwise, network effects tend to the local optimum of a single VCS
Which is why jj is interesting, it managed to find a way to coexist within the Git monoculture rather than swim against the tide like Mercurial, Darcs, Pijul, Fossil
This is a good point, git is more like a very clever toolbox than an actual "version control system". You can certainly implement a vcs using git, but it doesn't exactly start out as one.
If you could make it opinionated in one or two ways, how would you do it? I'm having a hard time thinking about situations that would be solved by this
Actually, the more I think about it, the more I realize the problem is that Git is too opinionated about a bad idea: attempting to make a DAG feel like a linked list in order to make it "easier" to use from the CLI because CLIs make it way too hard to visualize DAGs (don't come at me with your CLI DAG viz. Even the best ones are strictly inferior to the simplest GUI DAG viz).
There are really only two things I care about: the state of the files on disk and the state of the index. And I really only care about where I am and where I want to go, everything else in the middle is noise.
To me, the staging area isn't "real", it's just a tool for working with the other two. Git doesn't need to pitch a hissy fit about editing history. Allowing easy edits of history would obviate the need for the staging area. But because they called it "history", now we have emotional responses to the concept of editing it, like we're somehow committing political revisionism.
But the existence of the staging area and the attempt at making the DAG look linear makes reseting ridiculous. Every time I need to do some kind of reset that isn't --hard, I have to read my Git GUI's descriptions of what each type does, and yet somehow it still doesn't have the combination I actually want half the time. All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index. Sometimes I end up having to do a two step reset of a combination of hard forward then soft backwards to get what I want.
Similarly, all the different merge strategies are dumb. None of them ever do the right thing. I'm always getting stupid shit like new blocks that insert a new ending curly brace after the previous block, followed by the new block body, then the original ending curly brace from the old previous block. Half the time I just use the reset hard/soft to then manually review changes to enact a manual merge rather than trust merge to do anything reasonable.
Sacred history makes it way too hard to organize commits in any logical way. I want my VCS to be a super-powered UNDO. I don't need it to be an audit log of who did what and when (auditability only matters for releases so why do I have to be saddled with it minute by minute?). I basically want to be able to edit two or more commits in a sequence as easily as I currently can edit the staging area, so I can easily guarantee ordering of changes to partially related modules that I'm working on together. C depends on B depends on A. I want to be able to work on all three at the same time, but make sure all changes to A come first, then B, then C, and I want to be able to do this incrementally over the course of the day, rather than all at once when everything is perfect.
But this fetish of not changing history even though we can totally change history biases all other Git tooling to attempt to appear like it operates in linear history. Like how there's the HEAD pointer that can be offset; uuuh, what happens if that offset reaches a fork (I've never tried, the poor DAG experience of the CLI has kept me in GUIs which makes the HEAD pointer completely unnecessary). Or how log is basically unreadable.
Don't even get me started on submodules vs subtrees. I have to get to work.
> All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index.
It sounds to me like you want `git restore -W` and `git restore -S`.
I definitely agree that some people are too fixated on "not changing history". I've never mentally had any problem with this and do it all the time because I think it makes things much clearer and easier. If you're restricted from ever amending or rebasing, I understand why you hate it.
I'm having a hard time understanding the issues you're having with reset and the workflow. It sounds to me like you just need to do something like "commit 'WIP A'/'WIP B'/'WIP C'" and fixup them as desired. Things like https://github.com/sjurba/rebase-editor make it a lot faster to do this. It wouldn't be too hard to make a small script/alias to do something like "modify commit A with <staged>, stashing the rest, rebase B->C on top of A, unstash", and assuming they aren't touching the same lines significantly, it wouldn't conflict much. But this could be way oversimplifying what you want.
Thank you for the many tool links! You seems to know this space well. I have come to pick your brain for more.
I have been searching for a while for good tools to split/regroup diffs in a patch series. hunk.nvim looks interesting. Do you know of similar/competing tools?
I frequently hit a problem where removing a spurious hunk from an old commit causes cascading conflicts in all subsequent commits. Are there tools to propagate hunk removal into the future without the manual conflict-resolution pain?
Not the GP, but I might recommend Jujutsu for that, try it and see. It does the right thing when you resolve commits, and it propagates them to git. However, I'm not sure if it'll work, try it and see.
I can't help with your actual problem but I am incredibly curious about how/why you run into this so frequently you need a tool for it. I feel like in my 15 or whatever years of using git I have basically never wanted to remove a hunk from an old commit or anything similar.
I try to leave a good commit trail in my PRs. These are often _not_ the reality of how the code was written and originally committed, but a rough approximation of the intended steps with the benefit of hindsight.
git absorb works surprisingly well. I was quite skeptical in the beginning, but it really turned into something I used daily (until I switched to jj, where I haven't found a replacement yet). If you use stepwise commits I can really recommend it.
small edit: It seems that jj supports `jj absorb` now as well. Wonderful!
Indeed, though I don't think it can create fixup commits if that's what you're looking for. However, it might work great for that if you pair it with jj-spr: https://github.com/LucioFranco/jj-spr
I am often responsible for landing branches created by colleagues who are less disciplined about their diff cleanliness than me. Very often, attempting to regroup a spurious change from an early commit to a separate "cleanup" commit results in a long conflict hell.
Jujutsu is much better than git, and I've switched to it completely, but I do still use lazygit for one thing: It has better diff viewing, it separates the diffs by file and they look nicer. It's the only thing keeping me on lazygit, as jjui is much better otherwise.
also just to add that I've noticed that `jj` comes way easier and more intuitive to newbies I've mentored. Just yesterday I told a friend to commit his changes and he just wanted to do `git commit` (without remembering to do `git add` first). This made me realize we should just install `jujutsu` for him and he's been committing very diligently afterwards. Can recommend trying this with any people you mentor/teach.
That's also my opinion, that jj should be easier for juniors to pick up. However, I felt like there's a lack of learning material targeted at people without prior VCS experience. That's why I wrote "Jujutsu for everyone": https://jj-for-everyone.github.io/.
just to add to the chorus, I'm switching to jj as well. I haven't started using it in every project but it's only a matter of time I think.
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
You might laugh, but in years of serious development, I have not come across a better git UI tool than SourceTree.
If I want to be hard-core, I'd use the original git CLI. SourceTree is unmatched in how it makes using git so much more pleasant for when you need to do something relatively simple, but which would be quite cumbersome to do with the CLI and most other tools I've tried.
Its file status and history view is unmatched IMO. I can easily stage/unstage hunks and even lines. The whole UI is generally quite polished and pleasant to use.
It's a real shame there is not a version for linux. I've tried every other git interface under the sun and keep coming back to it. In the meantime, I tried lazygit the past weekend and I think it is one of the better TUI git tools out there, definitely better than GitUI.
On Windows I've been using TortoiseGit for over a decade now and in terms of Git power user features in a GUI I think it's unmatched.
People who defend the CLI as the only real way to use Git simply haven't used a decent GUI for it. I consider myself a very advanced Git user, but I barely know the CLI commands off the top of my head.
A GUI really makes a lot of sense for something like Git, most of the time what you want to do is "contextual' from something like a list of files to commit or a log of commits and TortoiseGit is pretty good about exposing whatever you'd need to do.
I find that with GitKraken (aside from not being free), I just don't feel in control of what I'm trying to achieve with Git.
Git Extensions seemed pretty decent and possibly a nicer GUI paradigm than TortoiseGit, but when I tried it I found TortoiseGit to offer more power to me.
One thing that does annoy me a bit about TortoiseGit is that it has this philosophy of a new Window for everything, which for most things is not a problem, but is in a couple of places. For example, to work on a repository you tend to have to use the Explorer context menu to do things. I tend to open the git log window once and leave it open, and from it I can do pretty much everything. If it had some sort of "main app" view with a tab per repository you have open that would be awesome, instead of my having to have multiple open log windows. Similarly, for commits and PRs I like to double check each file's diffs. Its UI opens each one in a new window, but if it would rather have a sub pane from the commit view I think it would work better.
I used to use SourceTree in conjunction with TortoiseGit because I liked its tabbed UI for the simple things like pulling/fetching/pushing, switching branches, but I stopped using it about 5 years ago, the Windows version of it felt neglected in that it would often crash or become very slow.
Man, those are 2 apps I haven't touched in decades. They felt novel at the time, but they just aren't as fast for me since it requires leaving my IDE which already has both CLI and visual git methods (I use intellij products)
There are two of us! I also espouse the virtues of TortiseGit any time I am able! I do take a bit of guff at work, but one feature of TG I've never seen equalled is how it handles what I call "drill-down git blame adventures". TG'a blame lets you easily keep going down through a files commit history in a way that is both intuitive and useful. My only issue with TG is that it is so Windows-focus and as I'm working more and more in Linux I will tragically need to leave it behind ;_;
Did you try magit? There's a bit of learning curve as it's built on top of Emacs, but it's entirely keyboard driven. I still have to find a workflow that it does not support.
Magit[0] is so good that I haven't felt any real need to use jj... yet. I'm sure I'll switch if it gets emacs integration of a similar level to magit, but the one I tried[1] isn't quite there yet.
I think the big thing (potentially, for me) is the ability to postpone conflict resolution during a rebase. That can be quite painful in regular old git, but git-mediate helps make that less painful in practice in my particular situation and workflow.
We'll see once better non-cli UX appears. I'm low-key excited for what could be possible in this space.
I am excited too! It is probably too much to hope, but I nonetheless am hoping that magit gets a jj backend before I have enough motivation or need to learn a new tool to do the same old stuff :D
Not who you are replying to, but I have bounced off of magit at least 3 separate times of trying it. I have been using both git and emacs for many years. Something about it just refuses to "click" with me.
FWIW, jujutsu was an improvement over git for me in about 5 minutes of using it.
Big fan of sublime merge. I recommend it a lot to people who need to dip their toes in source control and want some layer of abstraction, but also want to feel like they’re connected to the underlying tool (git). Merge balances this very well.
I know a lot of devs hate on Perforce (and I am no exception), but I've grown to actually really like p4merge (the Perforce merge tool) for handling conflicts.
It's a bit of an odd one, and it has a bit of a learning curve, but it's free (as in beer), relatively easy to install, and seems to work well for me. I haven't found a FOSS tool that I like as much yet.
I don't think I've actually used Kdiff3. I always assumed that it was Linux only but apparently I was objectively wrong about that. I should give it a shot.
For staging/committing I haven't found anything that I've liked more than Git Extensions' Commit view.
One of the main things I like about it is that it does _not_ auto refresh. A long time ago with SourceTree I'd have issues mixing git CLI and SoureTree because two processes would be doing things at the same time (I assume SourceTree was doing things like `git status` while I was trying to `git fetch` or something).
You can do "see only current branch" with the little filter icon when you hover next to a branch. Although I do find myself getting lost amongst branches more easily compared to Sourcetree, I think there's some difference in how filters are combined that isn't ideal (but I can't remember specifics)
You can also go to View in the menu and click "Filter by active branch" (Ctrl+Shift+A).
Also if you, like me, wanted to blame or view history for specific files there does not seem to be a way by clicking in the GUI to achieve it. But by using Ctrl+P you get the command search and can search for "Blame" or "File history".
Another vote for Fork here. Used to use many different UI clients, including ST and Tower but left Tower for Fork. I still add P4 Merge as my external merge tool though. It seems to have the best algorithm and often solves conflicts automatically.
I love Tower and have paid for it for years. I can’t imagine using the git CLI now. GUIs were invented for a reason and the git CLI has terrible ergonomics and many ways to make costly mistakes.
It's pretty good but also really slow. I never found one better than GitX, but that was in the days before IDEs had Git support built in. Now they do it doesn't really make sense to use a separate program IMO.
These days I use VSCode and the Git Graph extension.
+1 for GitX. For some reason the most recent version in GitHub doesn't work well for me anymore, so I keep an extremely old version (Version 0.15.1964 dev (0.15.1964) in a Dropbox folder and it's my daily driver for years.
I think there's a learning around stability of devtools here. It takes time to get used to things, but once you do you are ultra productive. That's why IDE Git UIs are not ideal, because the graphics change so often, confusing you more than helping etc.
I got stuck to git gui / gitk for so long for this reason, I couldn't parse other UIs e.g. for diffs until I forced myself to have a less productive time to learn new UI.
I hope lazygit is stable - I think I might need to construct some stable config for visuals / colors to ensure this! (:
Its good but actually a little slow at times. For a big repo, it feels like they're handling a few commands synchronously and it hits IDE performance, when they should really be showing some kind of async spinner and yielding so the rest of the IDE continues.
I've been using SourceTree for years, mainly because I like the staging experience. I've never felt good about it though, I don't know why I've put up with the terrible performance for so long. I recently stumbled upon https://github.com/sourcegit-scm/sourcegit and it's totally replaced SourceTree for me. Very similar (or better) UI/UX but much more performant.
I was using SmartGit for many years and was very happy with it, until they made it subscription based and had to switch to SourceTree. It works but I do not find it very smooth at all. It hangs every now (using MacOSX) and in general the experience is not as smooth as it was with SmartGit. I am surprised that you are saying that you haven't come across any better tool.
For a few minutes after reading this I was worried about smartgit losing its way. But it seems they actually still offer perpetual single-payment licenses, where you purchase a few years of updates, usable after update period ends.
Fellow SourceTree apologist here. It remains one of the first things I install on a new machine. I'll do simple stuff directly in the CLI, but stick with SourceTree for anything moderately complicated (as you've mentioned).
If you don't mind a TUI, I've been very much enjoying gitui - in fact, this is the second time I've recommended it recently. Adding hunks and single lines is easy, and the various commands are all visible, so it lacks the usual TUI experience of "what key do I need again?"
If you're down to try it, I actually think SmartGit is a similar style but ended up working better for the slightly more exotic things like submodules.
There are few UI's that I hate more in the world than SourceTree. That pile of junk has cost me so many hours of life trying to support the developers in fixing a thousand weird issues.
What exactly were the problems? I have been using it since like forever and have not run into any issues at all. Granted, like I said, I don't use it for any hard-core stuff.
The Windows version is decent too. They seem to be at least partly different code bases, which is nice in some respects, but does mean they're not quite the same. The Mac version is less good about doing git submodule update when required, and sometimes the side panel state can be wrong; the Windows version seems to occasionally forget the state of the delete after applying option when doing git stash pop.
Despite having some annoying aspects, it is (as if you even needed to ask) still better than using the command line, and, importantly, has yet to annoy me enough to actually switch to something else. Though as an Emacs fan I do have Magit on my list.
The less I use git directly, the more convinced I am that git is an absolutely awful interface to git repositories. I have been using jj for about two years now, and I literally cannot imagine going back to using the git cli. I have not used lazygit, but if you find it interesting, I say please go for it.
The please is because I am tired of fixing issues created by people being confused by git. Just use anything else than the git cli, it's probably better.
I have tried jj several times but I feel like it slows me down significantly because I can’t grok the workflow. I like to do a bunch of changes then quickly select them in my editor and commit them, breaking them up into different commits to keep them organized. With jj’s lack of editor integration, I don’t know how to do this with the cli alone so I end up with bigger messier commits.
Or if you don't care to set a commit message just yet: jj split -i
Or if you want to defer making sure each commit has the right content until later, just use jj new, and then later use jj squash and jj split to make the commits have sensible changes, and jj desc to set the descriptions.
The compatibility with git is the whole reason it's so popular (just run `jj git init --colocate` in your git repo).
You can use it without forcing your collaborators to switch from git and you can use it will a git forges as well.
I don't think you need `--colocate` any more, and maybe you don't even need `git`? I tried `jj init` in a git repo the other day and it did create a colocated jj repo, as far as I could see.
Wait, no one mentions the default JetBrains IDE git UI? I mean, I get it if you're working from another IDE/text editor that doesn't have good git UI support out of the box, but JB's git UI is reasonably good enough that I don't want anything else.
Things that I use (and I like):
1. quick checkout to another branch and automatically stash and unstash your local changes; when I just need to inspect code elsewhere I find it really useful. My changes are small so I can always remember to stash them later;
2. compare branch/commit etc via UI; again I know you can do that in git diff, but then you would need to know the command and the commit SHA to compare; in UI it comes in really handy, just select the branch or commits you want to compare and that's it. I've seen my coworkers trying to come up with the command and I just say: use IDE and a couple of clicks they got it working.
3. filter commits by user and by folder.
That's a great point. I should have mention the IDE Git UIs, def a nice option and sounds like the JB one works well for you!
I do use it heavily for "annotating git blame"!
I've never consider using JB Git UI fully mainly because of the point made earlier, so stability (https://news.ycombinator.com/item?id=45898089). Once you learn, especially visually, you don't want cosmetic changes. IDEs change yearly to stay "consistent".
Another point is portability. E.g. I didn't want to pay for personal use of JB (so rare case), so I have to use different IDE. Separate tools (especially free and OSS) is a big advantage. Not mentioning ability to use it on remote shells or different machines!
lazy git offers 1, but 2 and 3 points are interesting. Wonder if there's an easy way to compare commits and filter commits by user and folder in lazygit. (:
EDIT: Actually, I also use JB for conflict resolutions ;P so not entirely 100% lazygit flow.
I don't think JB UIs been changing that much, albeit I haven't been working in the industry long enough. I think the last major UI redo was like 2,3 years ago and most of it is to make UI more compact, and I definitely like it. That being said YMMV.
IMHO another good thing of using JB IDE git UI (especially in a corporate setting) instead of using another software is that everyone has the IDE so it's easier to collaborate. Imagine if you're helping a junior member debug their local branch and they don't have lazy git installed.
The diffs are the biggest reason I use it (beside the 3-way diff, I can't live without: blame, optimize imports, all the editor functions inside the diff, diff files/commits/branches).
Beyond that: separating into change lists (staging changes by line inside a file) and the graphical presentation and filtering of the commit history (highlighting what commits are in/out of your branch, show the git history of a section or line of code, show repo files at a commit)
Oh, I didn't know it. It looks pretty useful, but it requires more mouse usage than I'd like and its window is not very well suited for tiled window managers straight out of the box.
Yeah I have a rule in my i3 config so it gets focused and fullscreen. It does require mouse usage, which is why I wonder why I like it over say, lazygit. I may switch, but yeah, thought one should know of its existence, it is a cool piece of software, too.
A large percentage of git users are unaware of git-absorb (https://github.com/tummychow/git-absorb). This complements just about any git flow, vastly reducing the pain of realising you want to amend your staged changes into multiple commits.
This sits well alongside many TUIs and other tools, most of which do not offer any similar capability.
I gave it a try a few months ago, and wasn't impressed. About a quarter of the time it got confused about the commit it should squash into, and left the repo in a half-applied state. This inconsistency was enough for me to not trust it when it did work, so I stopped using it.
Honestly, it's too much magic for my taste. And, really, it's not much manual work to create fixup commits for the right commit anyway.
I see the usefulness. But my client is magit, and committing and rebasing are so quick that this will reduce perhaps 30 seconds to one minute to my workflow. And I do not like most rust tools, because they're too dependency heavy.
Definitely. The instant fixup feature is just three keystrokes away (s c F). The only thing this helps is when you don't want to spend the extra brain cycles to figure out which commit to fixup on.
The task that absorb speeds up is finding the commit where each hunk was last changed. The actual committing and rebaseing is still basically the same.
Git blame using `M-x vc-annotate` with Emacs. But If I have a clean PR that usually means one to three commits (If it's not a big refactoring). So the whole point become moot. In magit, if you create a fixup or a squash commit, it will present you with the log to select the target.
Yes, or magit-blame, but if you still have multiple commits in your history that you are working on, and you need to break up the current changes in a bunch of instant fixups, figuring out which one is the right one can be a bit time consuming. I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.
People often avoid it because of the name, but Github desktop is pretty amazing. It works great with all git repos (including ones not on Github), and makes it super easy to amend commits and cherry-pick files/lines to include. Everything has handy names, and all the complex operations have text explaining what they do.
GH Desktop's merging, conflict stuff, and (lack of) graph leave much to be desired, but it's already 1000 times better than the git cli. Whenever I have someone who hasn't used git before joining a project, I always get them to use GH Desktop - it's easier for them to understand what's happening, and reduces the messes they cause compared to running random git commands from stack overflow.
Seconding GHD. They have added features very slowly, very thoughtfully; HN tends towards experts (or at least people who think they are). I am aware that I'm NOT good with git. I will never do anything that has "hard" or "rebase" in it without spending 20 minutes making sure its what I want to do. Unfortunately I have seen way too many semi junior engineers who think they're git lords who force push bad histories and ruin our git repo. I tend to suggest strongly that people should use github desktop if they are in my team though very few people take up that suggestion :)
It's very hard to destroy things with git. Every action is stored with the reflog. Then also, in a team setting, you should want the copy on the forge to have protected branches so that no one push (or force push) on them.
Something not mentioned in the article which has changed the way I interact with git repos (and the reason I will never not use LazyVim until something better comes along) is just how well the system plays with tmux floating panes.
I have it so that anytime I press ctrl-g in a git repo, I open a floating tmux pane in my current working directory. This might sound "whatever", but it means I don't have to actually be inside neovim or "switch" to the LazyGit UI. It just overlays it on top of whatever I'm doing at the moment in the terminal.
Makes for the most fluid, streamlined git experience ever if you primarily live in the terminal.
Personally I just couldn't see all the extra layers as comfortable tools. It's a very rare thing that I need to see branches, relation between them etc. Using cli has always been the most reliable and simple way for me.The only git tool I need apart from cli is a convenient conflict resolver.
Lazygit is great, I use it all the time for straight forward git-fu.
I do recommend turning off force push (there is an option), as it's easy to fat finger and leads to a whole lot of heartache.
But if you do any advanced work that involves merging a complex codebase across multiple branches, with generated code and multiple languages; and having to manage your load of conflicts, I find Fork[1] (the free version does fine) still takes the cake for that, as the clarity and lack of keyboard bindings, is essential; to make good, conscious decisions.
To be clear, there isn’t a free version. There’s a cost-less download that’s meant for evaluation purposes, with the goal of paying them if you like it and find yourself using it long-term.
Given that Fork is a two-person family company that’s somehow managed to make the best Git client in the world for a single reasonable price with free updates and no subscription, I’d suggest that it’s worth paying for to keep their business sustainable.
In general, the tool looks cool. It also looks like it takes time to learn; but if you find it useful, it's probably worth it taking the time to learn.
There were two blockers for me:
1: I can't free-form select text with a mouse like a can in a terminal. (I honestly haven't used a TUI since the 1990s.) I frequently copy bits of branch names from the terminal, so this was a big deal for me. There is a way to "disable" the mouse in lazygit, which then allows copy & paste; but as I prefer to learn a program with point & click, it's a non-starter for me.
2: A lot of this functionality is built into Visual Studio for me. I use a mix of Visual Studio's point & click with git, and then the git command-line: Whichever is easiest for the specific task I'm doing. It just takes a bit more exploration in Visual Studio to find this functionality, as opposed to it being front and center when starting lazygit.
1. Yes, it's been a frustration initially, but it has a nice benefit - it forces you to use native features (e.g. patch based copy/reset). Apparently it's on the radar, but not implemented yet: https://github.com/jesseduffield/lazygit/issues/4365#issueco...
2. Yes, see https://news.ycombinator.com/item?id=45898167 discussion. Using IDE is great if all your machines has this IDE installed (and GUI in general). The stability (graphical layout) is likely changing often though.
"git gui" is not just a wrapper for commands; it has usefully different workflows.
For instance, you can visually select a range of lines in a file, and stage those lines.
This is much easier than doing "git add --patch" and using edit, where you are deleting unwanted lines starting with +, turning - lines into context and whatnot.
I have found it useful to fire up "git gui" during rebase workflows with conflicts. It helps with the "git add" commands you would have to do to add conflict-resolved files into the patch and whatnot.
No idea; I don't know every git gui; I'm talking about that Tcl/Tk thing that is literally run with "git gui".
It would be pretty pointless to go out of the way to use something that doesn't come from the git project, yet is less capable (unless it had some overriding killer feature for the sole sake of which it was invoked).
What! I was git gui user for decade and didn't notice this feature =D But yea, git gui is amazing overall. I don't think it's maintained anymore though.
BTW lazygit offers that too and it's a bit easier to discover and use (e.g. you don't need a mouse).
Am I the only one who simply doesn't mind Git's CLI?
Sure, it's rough around the edges, but I know those edges well. I sometimes do need to look up how to do something, but those cases are rare. Over the years I've accumulated about a dozen shell aliases and a modest `.gitconfig`, and along with a couple of helper tools[1][2], I can do 90% of what I need Git for in seconds. I truly don't need a fancy TUI, GUI, or any wrappers around Git. Git itself is fine.
I tried Magit a few times, and even though Emacs is my main editor, I couldn't get used to it. It forces the user into doing things the "Magit way", and I'd rather not.
I don't understand the push to replace Git's porcelain with something shinier. If, and when, a better VCS comes along that truly feels like the next step forward, I'll give it a try. In the meantime, Git does the job I need.
I can use the CLI, but magit is mostly CLI on steroids. All the information you could have accessed through the cli is quickly available, and they are active objects, meaning subsequent commands will take that into account. Any mutation is also available through quick keybindings as well.
The one thing that I truly like about Magit, and the builtin vc-mode, is that I can focus for a couple of hours on coding, then quickly create a serie of commits to capture that work. Like doing line art after sketching. I like when administrative work (filing patches under commits) is isolated from creative work (solving problems and designing practical solutions).
No - unless you took away my gitconfig, which is pretty big at this point. Though I guess that's mostly a time-saver. Even so, I've found most of the GUI tools to be confusing because it's hard to tell what they're actually doing under the hood.
I do use sublime merge at times though now - it's nice for [un]staging individual lines and for looking at some diffs. I also like git-foresta[1] more than log sometimes. I'll have to check out scmpuff - it should be easier than going through a patch add.
I do not mind the Git CLI, and I just carry around my alises. I also built a tool to make it even more powerful and integrate with issue trackers:
https://pypi.org/project/gibr/
I completely agree, and I would add that in just about any dev role beyond being a junior it's so common to need to work efficiently without much of a dev environment anyway.
There's just no point in fighting this battle. I will admit it's sometimes nice to have fancy tools, but they're just that. I don't get the need to make a hobby out of it when there's so much other stuff to do.
> Am I the only one who simply doesn't mind Git's CLI?
No, but by definition, Git's CLI doesn't scale for complex use cases. No one would voluntarily use the CLI for doing a complex 3-way merge if they could avoid it.
Due to the complexity of Git's interface, it's too easy to make a mistake using the CLI. I get we don't use most of the options most of the time, but when you need them, they're not exactly discoverable.
> No, but by definition, Git's CLI doesn't scale for complex use cases.
How so? A CLI is where you run commands and things happen. Sometimes those things can be "complex", whatever your definition of that may be.
> No one would voluntarily use the CLI for doing a complex 3-way merge if they could avoid it.
And nobody does...? A manual merge is done in an editor or a standalone tool, not the CLI.
> Due to the complexity of Git's interface, it's too easy to make a mistake using the CLI.
Well, Git's UI can be intimidating for a newcomer, but once they're acquainted with the dozen or so commands they might need every day, they can define aliases for them, and mistakes are no more likely than with any TUI or GUI wrapper. Git by design gives full control to the user, so mistakes can happen, but this is no different than with most Linux tools. And if safety is a concern, then whatever hand holding a TUI or GUI does, the same can be implemented in a shell script.
> git commit alone has 40+ options
So? You would prefer less options? Less commands? Less flexibility?
Just look up what you need to do and how to do it, and stick it in an alias. Now you have a clean command purpose built for your use case, and you can ignore anything you don't use.
Or, you can use a fancy TUI/GUI wrapper that "simplifies" this interface for you, and then when you need to do something that the wrapper UI doesn't allow you to do, have to fall back to the original UI. I'd rather familiarize myself with the original UI, create the aliases and helpers that work best for my workflow, and not have to depend on someone else's idea of how I should use Git, or any other tool.
I've read the Jujutsu documentation and a lot of praises for it, and its most compelling feature is a simpler UI compared to Git. There have been other VCS tools with arguably better UIs and feature sets than Git (Mercurial, Fossil), and yet they haven't gained traction, for better or worse. The only reason jj is having more momentum is because of its compatibility with Git, which was a smart decision by its developers.
A better UI is not something I would consider a next step for a VCS tool. I can do that myself with my shell and small helper tools. Whereas features like semantic and binary diffing would be compelling generational improvements over Git. I know these can technically be tacked on to Git itself, but a VCS built for them would be able to do things Git simply can't. These are just two I can think of, but a next generation tool would be evident without requiring much explanation. Just like DVCSs were over the previous generation of tools.
jj is not just a simpler UI. Its rebase is fundamentally more powerful than git, it has things like the operation log, first class conflicts, etc… that git doesn’t have.
VS Code is free, cross-platform, many people already use it, and has a very good GUI interface for git.
It can easily do all the common workflows.
I mainly use the CLI but if I already have a project open in VS Code I'll just do it in the GUI because it's actually faster in many cases and sometimes a bit more intuitive.
Lazygit, WezTerm, NeoVim, Yazi (TUI file manager) are a fantastic combination! I have a tmuxniator config file for every project I work on. And open a tab in WezTerm, run „mx projectname“, it opens a split for Yazi, one for Lazygit, one for neovim, and one for my agentic coding tool. Lovely setup, super fast, all in the terminal.
The king of all alias is fixup, which commits everything and fixes up the commit with the previous one.
Another script just goes over the changes and allows me to add/skip/restore.
Then I can pipe the log to another script that will analyze tags and tell me what is not yet in prod.
cli is hard... but it composes. I want to know that CLI as well as possible. And I don't want to start from scratch each few years with a new UI / concept.
Off-topic: but the README of lazygit is awful with all those sponsors at the top. I hope Github comes up with a better way to list sponsors that favors developers and allows them to exclude them from the README.
I'm the "git guy" at every place I work and I don't touch the git CLI. Been using Magit for 15 years now. I just don't think a CLI is a good interface for state mutation.
CLIs are perfect for functional interfaces, like grep, sed etc. But I think they are very hard to get right when side effects are in play. Really basic things like mkdir and rm are ok, but when you have enormously powerful things like git rebase I find it difficult to keep track of what's going on.
I wonder what a more functional Unix would look like... Instead of mkdir just write to any path, instead of rm just overwrite a path with nothing, maybe we'd accept that mv would be implemented as "porcelain". The balance I think is keeping a lid on how complex that porcelain can become, and git has way overstepped the mark. So I prefer GUI/TUI interfaces for mutation, and Emacs is the best there is for building those.
For folks looking for a GUI tool, SourceGit is quite nice.
Written in C#, cross-platform (I have only used it on linux) and a cleanly-designed conventional ui that doesn't aspire to radically alter your workflow.
In the example of how they were removing specific lines from the previous commit, git gui had a way to do that instead of copying the diff lines and manually editing them back into the code:
git gui → Amend Last Commit → (select lines from a file in the Staged Changes area) → Unstage Lines From Commit → Commit
I still think it's the perfect does-just-enough GUI when the main thing you want is to visually craft commits.
I've found the built in gitk is pretty good for some GUI tasks. If I want to view the sate of some file at a given commit, it's easier to navigate using that rather than going through git log, find and copy the commit, git show, paste, copy the file path. GitHub desktop didn't seem to have this feature last I checked, even though the GitHub web viewer does.
The git integration in VS Code has gotten really good lately. It has the commit graph, with cherry picking, worktrees, stashes and a very nicely integrated merge editor and rebasing, along with all the common commands. Also staging individual sections and lines visually, which I use daily
I recently started working on a repo which historically had 100+ parallel branches. I've been jumping between a few tools recently trying to find something which handles browsing these sanely - I always liked browsing graphs, but the sheer amount of branches ruins most of them.
Currently the best workflow I've worked out is just a plain
git log --oneline --graph -- <dir>
Followed by showing the specific commits. But this doesn't work so well with MRs that touched many files across different dirs. Anyone have suggestions for tools that might handle this better?
After a short stint when I had to do dozens of small edits to files, this became something I use every day (and I am the sort of person who types git commands by choice, even inside VS Code…)
Haven't regretted it at all; the tool is a pleasure to use due to its great design decisions. Contributing back to the codebase is also quite straightforward.
My current setup is just a few alias commands and I use gitin instead of "git log". I really wish that tool was still in development because it provides a really nice minimalist design for exploring git repos: https://github.com/isacikgoz/gitin
I think git can do partial checkout these days, you can even filter which parts of the history to store locally, like download all commits, but not the file content for them, and dynamically load them when needed.
Committing Changes:
SVN: svn commit -m "Commit message" (commits changes directly to the central repository)
Mercurial: hg commit -m "Commit message" (commits changes to the local repository) and hg push (sends local commits to a remote repository)
Deleting/Removing Files:
SVN: svn delete <filename> or svn remove <filename>
Mercurial: hg remove <filename> or hg rm <filename>
Branching:
SVN: svn copy <source_URL> <destination_URL> (creates a branch by copying a directory in the repository)
Mercurial: hg branch <branchname> (creates a new named branch within the repository)
Reverting Changes:
SVN: svn revert <filename> (reverts local modifications) or svn merge -r <revision>:<revision> <URL> (for more complex reverts)
Mercurial: hg revert <filename> (reverts local modifications) or hg backout <changeset> (to undo a specific commit)
One really nice thing about a distributed version control system is that it lets me as a developer make commits to track my work without having to push them to a central location and pollute the global commit history of the repository. I can modify my commit history (to clean it up and remove all of my failed experiments, for example) before I publish it, so to speak. Or I can completely remove my commits without publishing at all if what I was trying didn't pan out.
Last year, unfortunately. Most modern utilities, even svn-to-git migration utilities, have been abandoned now that git has become the de-facto standard and everyone who can reasonably be expected to switch to git has done so already.
Lazygit is the only way I review PRs these days because it is trivial to step through a file commit by commit when that is necessary (which maybe says something about the quality of the PRs I'm reviewing...). They also won me over by using Legend of the Galactic Heroes references in the github readme gifs.
Been using gitkraken for ages and still like it, but they do make it harder and harder to like every update. The enshittification seems to have started and every update seems to bring more and more ai features, and pushing more ”cloud” features as well
the only good git GUI that exists is Fork. Unfortunately, it doesn't run natively on Linux, although some people have had luck running it under Wine.
I found lazygit specifically so bad to the point that I was better off typing in git commands into the terminal manually like some sort of caveman. Somehow, lazygit has found a way to make git even more confusing and user hostile than it already is, which is a significant achievement.
Using it was a harsh reminder of what people running emacs or vim for the first time have to go through.
This idiotic ui paradigm where you have to actively learn to use what should be simple software by memorizing commands and shortcuts needs to die off. It's mind bogglingly inefficient and disrespectful of user's time.
Just think about it - I've literally never had to open Fork's manual (I am not even sure it has one) whereas in lazygit it is utterly impossible to do the most basic things without referring to the manual. Why do we collectively keep tolerating these shitty tools?
Wow, $60! It had better be really, really good for that price.
I managed to get on fine with lazygit during a quick trial this morning. It actually doesn't have a manual (`man lazygit`: `No manual entry for lazygit`) but I found the contextual help (e.g. press ?) useful.
Tower is also very good. Probably just due to having used it more, I prefer it over Fork, but I can get by if I have to use a computer not licensed for Tower.
As much as I heartily disagree with most of what you wrote - and seeing all the downvotes, I'm not the only one - there is a nugget of truth in what you wrote, which answers a lot of your complaints.
"Using it was a harsh reminder of what people running emacs or vim for the first time have to go through."
The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
Mouse-driven tools like VS Code don't demand that the user learns them. Keyboard shortcuts there are optional, since practically everything is in a menu or a UI that can be moused to. This adds on seconds per interaction, adding up quickly over time.
+And the "learning" for these tools can be shortened dramatically by keeping a printed-out cheatsheet. For Vim this can be a huge lifesaver; I made one for magit as well, back before I switched full-time to JJ.
> The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
I have never been rate-limited by my keyboard input speed. I have lost many minutes of time daily looking up cheatsheets for terminal tools that I use occasionally.
Ironically, when I see what impact AI has had on my programming, the biggest has been in saving me time crafting command line invocations instead of browsing <tool> --help and man <tool>.
The speed change you see is not due to raw input speed, but do to eliminating a context switch in the brain. I thinking I want to see X and already seeing it on the screen.
> Mouse-driven tools like VS Code don't demand that the user learns them.
Honestly, I found the barrier to entry way lower with lazygit than with vscode.
I realise I'm not adding anything useful to this discussion. I tried to start VSCode so that I could evaluate it and, maybe, add some info. as to why I find it more difficult to get into, but it just crashes now :shrug:
> The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
This is simply not true and I say this as a life long vim user. The only reason I have vim mode enabled in all the editors that support it, is the fact that it's immensely difficult to retrain muscle memory accumulated from a decade+ time sunk in that editor. Nothing about vim or any of these other tools being keyboard driven, make me more productive in a way that matters.
> Mouse-driven tools like VS Code don't demand that the user learns them.
Good. That's how all software should be. It's a means to an end, not the center of the universe. The whole reason for bringing a UI layer into all of this in the first place is freeing up my brain from having to deal with git's bullshit.
> Keyboard shortcuts there are optional, since practically everything is in a menu or a UI that can be moused to.
The shortcuts are still there if you care to learn them - it should absolutely not be a prerequisite.
> +And the "learning" for these tools can be shortened dramatically by keeping a printed-out cheatsheet.
Or, I could use some actually well designed software and save myself some printer ink :-)
> Or, I could use some actually well designed software and save myself some printer ink :-)
Or, you could use some well-designed and self-documenting software. Too bad there's not much of that besides Emacs - on the other hand, Emacs and occasionally a browser cover most of my computering needs...
I was a big fan of a good keyboard-driven git TUI like magit, neogit, lazygit, etc... (as long as you learn the CLI first and understand it).
Now I no longer directly use git, but instead use jujutsu (jj).
Once I became very proficient in the jj cli, I picked up jjui: https://github.com/idursun/jjui
Also, as splitting commits is an extremely frequent operation, this neovim plugin is really nice: https://github.com/julienvincent/hunk.nvim
Also this neovim plugin is amazing for resolving jj conflicts: https://github.com/rafikdraoui/jj-diffconflicts
Now with jj instead of git I edit the commit graph as effortlessly as if I am moving lines of code around a file in my editor.
I think a big problem with Git is that it's not opinionated enough. Every team has their own Git flow because Git makes it possible to do so and most developers love nothing more than micro optimizing every minute aspect of any work that is not the task they've been assigned this sprint (myself included), or avoiding learning anything at all (half of my coworkers) thereby leaving the decisions to people like me. I'd much prefer a tool that has one way to do things and everyone just had to "get with the program." Instead, we have this Swiss Army knife that can do anything but requires arcane knowledge of how to do things that are just slightly off the beaten path.
I'm very comfortable with Git and have saved coworkers in just a few minutes from what they thought was going to be missing days of work. But I'd much rather if they had never gotten into that situation or could easily fix it themselves. I don't like the idea of every software team needing a Git expert in easy reach just in case something goes awry.
The problem with an optionated tool that mandated a specific workflow is that people that can't follow this workflow can't use the tool
This follows the Unix principle of "provide mechanisms, not policy" (as I remember from the esr book on Unix philosophy - <imagine a link here>). Git provides mechanisms for version control and it's up to users, projects, organisations, etc to set up policy. That's because mechanisms are more universal, and policy changes with the whims of the stakeholders
(I actually agree that tools that mandate a workflow are more enjoyable. Not everyone needs to use the same version control and different DVCSes can or could be interoperable like git and jj are)
Yeah, I think we could use a little more of "not trying to be everything for everyone". If more opinionated tools meant there were five or ten VCSes in common use rather than 1 or 2, I think that would be a better world.
As long as they are interoperable, sure. Otherwise, network effects tend to the local optimum of a single VCS
Which is why jj is interesting, it managed to find a way to coexist within the Git monoculture rather than swim against the tide like Mercurial, Darcs, Pijul, Fossil
This is a good point, git is more like a very clever toolbox than an actual "version control system". You can certainly implement a vcs using git, but it doesn't exactly start out as one.
Makes me wonder what other tools could be implemented on top of git, besides a vcs.
I’m sure I’m not the first one to have that thought. So I’m curious what other tools and systems people have built in top of git.
In the past we would say google it but it's even more inexcusable today with LLMs.
And if something becomes really hard to do with git, I found that often the problem are on the project itself.
If you could make it opinionated in one or two ways, how would you do it? I'm having a hard time thinking about situations that would be solved by this
Actually, the more I think about it, the more I realize the problem is that Git is too opinionated about a bad idea: attempting to make a DAG feel like a linked list in order to make it "easier" to use from the CLI because CLIs make it way too hard to visualize DAGs (don't come at me with your CLI DAG viz. Even the best ones are strictly inferior to the simplest GUI DAG viz).
There are really only two things I care about: the state of the files on disk and the state of the index. And I really only care about where I am and where I want to go, everything else in the middle is noise.
To me, the staging area isn't "real", it's just a tool for working with the other two. Git doesn't need to pitch a hissy fit about editing history. Allowing easy edits of history would obviate the need for the staging area. But because they called it "history", now we have emotional responses to the concept of editing it, like we're somehow committing political revisionism.
But the existence of the staging area and the attempt at making the DAG look linear makes reseting ridiculous. Every time I need to do some kind of reset that isn't --hard, I have to read my Git GUI's descriptions of what each type does, and yet somehow it still doesn't have the combination I actually want half the time. All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index. Sometimes I end up having to do a two step reset of a combination of hard forward then soft backwards to get what I want.
Similarly, all the different merge strategies are dumb. None of them ever do the right thing. I'm always getting stupid shit like new blocks that insert a new ending curly brace after the previous block, followed by the new block body, then the original ending curly brace from the old previous block. Half the time I just use the reset hard/soft to then manually review changes to enact a manual merge rather than trust merge to do anything reasonable.
Sacred history makes it way too hard to organize commits in any logical way. I want my VCS to be a super-powered UNDO. I don't need it to be an audit log of who did what and when (auditability only matters for releases so why do I have to be saddled with it minute by minute?). I basically want to be able to edit two or more commits in a sequence as easily as I currently can edit the staging area, so I can easily guarantee ordering of changes to partially related modules that I'm working on together. C depends on B depends on A. I want to be able to work on all three at the same time, but make sure all changes to A come first, then B, then C, and I want to be able to do this incrementally over the course of the day, rather than all at once when everything is perfect.
But this fetish of not changing history even though we can totally change history biases all other Git tooling to attempt to appear like it operates in linear history. Like how there's the HEAD pointer that can be offset; uuuh, what happens if that offset reaches a fork (I've never tried, the poor DAG experience of the CLI has kept me in GUIs which makes the HEAD pointer completely unnecessary). Or how log is basically unreadable.
Don't even get me started on submodules vs subtrees. I have to get to work.
> All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index.
It sounds to me like you want `git restore -W` and `git restore -S`.
I definitely agree that some people are too fixated on "not changing history". I've never mentally had any problem with this and do it all the time because I think it makes things much clearer and easier. If you're restricted from ever amending or rebasing, I understand why you hate it.
I'm having a hard time understanding the issues you're having with reset and the workflow. It sounds to me like you just need to do something like "commit 'WIP A'/'WIP B'/'WIP C'" and fixup them as desired. Things like https://github.com/sjurba/rebase-editor make it a lot faster to do this. It wouldn't be too hard to make a small script/alias to do something like "modify commit A with <staged>, stashing the rest, rebase B->C on top of A, unstash", and assuming they aren't touching the same lines significantly, it wouldn't conflict much. But this could be way oversimplifying what you want.
Thank you for the many tool links! You seems to know this space well. I have come to pick your brain for more.
I have been searching for a while for good tools to split/regroup diffs in a patch series. hunk.nvim looks interesting. Do you know of similar/competing tools?
I frequently hit a problem where removing a spurious hunk from an old commit causes cascading conflicts in all subsequent commits. Are there tools to propagate hunk removal into the future without the manual conflict-resolution pain?
Thanks again!
Are you looking for solutions within git or jj?
In my experience with jj when resolving a conflict, as long as I do it in the earliest change, I will only have to do it once.
Git has the rerere setting [0] which reduces the need to resolve the same conflict over and over
0: https://git-scm.com/book/en/v2/Git-Tools-Rerere
Not the GP, but I might recommend Jujutsu for that, try it and see. It does the right thing when you resolve commits, and it propagates them to git. However, I'm not sure if it'll work, try it and see.
git rerere
https://git-scm.com/book/en/v2/Git-Tools-Rerere
I can't help with your actual problem but I am incredibly curious about how/why you run into this so frequently you need a tool for it. I feel like in my 15 or whatever years of using git I have basically never wanted to remove a hunk from an old commit or anything similar.
I try to leave a good commit trail in my PRs. These are often _not_ the reality of how the code was written and originally committed, but a rough approximation of the intended steps with the benefit of hindsight.
A tool like https://github.com/tummychow/git-absorb has been on my to-try list for a while, but for now I do it by hand.
git absorb works surprisingly well. I was quite skeptical in the beginning, but it really turned into something I used daily (until I switched to jj, where I haven't found a replacement yet). If you use stepwise commits I can really recommend it.
small edit: It seems that jj supports `jj absorb` now as well. Wonderful!
Indeed, though I don't think it can create fixup commits if that's what you're looking for. However, it might work great for that if you pair it with jj-spr: https://github.com/LucioFranco/jj-spr
I am often responsible for landing branches created by colleagues who are less disciplined about their diff cleanliness than me. Very often, attempting to regroup a spurious change from an early commit to a separate "cleanup" commit results in a long conflict hell.
Jujutsu is much better than git, and I've switched to it completely, but I do still use lazygit for one thing: It has better diff viewing, it separates the diffs by file and they look nicer. It's the only thing keeping me on lazygit, as jjui is much better otherwise.
Git doesn't fundamentally work with diffs (patches). It stores the complete file and generates a diff.
So you can use any diff tool you like with git, and I presume also with JJ. Look for the setting.
Edit: in git it's the diff.external setting
I know I can. I want to use jjui, but its UI isn't as good, so I use lazygit.
There's also lazyjj. I haven't really bothered with a TUI yet so can't say which has nicer diffs, but you might try it.
I've tried lazyjj, but jjui was better (at least, back when I tried it).
I've thought about using https://github.com/dlvhdr/diffnav for that
This looks very interesting, thank you!
also just to add that I've noticed that `jj` comes way easier and more intuitive to newbies I've mentored. Just yesterday I told a friend to commit his changes and he just wanted to do `git commit` (without remembering to do `git add` first). This made me realize we should just install `jujutsu` for him and he's been committing very diligently afterwards. Can recommend trying this with any people you mentor/teach.
That's also my opinion, that jj should be easier for juniors to pick up. However, I felt like there's a lack of learning material targeted at people without prior VCS experience. That's why I wrote "Jujutsu for everyone": https://jj-for-everyone.github.io/.
> I was a big fan of a good keyboard-driven git TUI like magit, neogit, lazygit, etc... (as long as you learn the CLI first and understand it).
How about tig?
just to add to the chorus, I'm switching to jj as well. I haven't started using it in every project but it's only a matter of time I think.
That said, I do which for a more jj aware GUI. For one, it's nice to be able to quickly see diffs across a bunch of changes. I use gg for this but I'd prefer a side-by-side diff and, ATM it only has a traditional diff.
Also, watching the video of git butler, it seems like a jj UI could take a lot of inspiration. I'd love to be able to just drag changes rather than `jj rebase ...` and/or drag selections of lines.
I'd also like a nicer GUI for interactive splitting/rebasing than the TUI UI built into jj
You can use VisualJJ to rebase via drag & drop, split interactively etc.
https://www.visualjj.com - I'm building it and would appreciate any feedback!
ooh that's interesting, wonder if that works better than git eorktrees when playing with multiple AI agents
You might laugh, but in years of serious development, I have not come across a better git UI tool than SourceTree.
If I want to be hard-core, I'd use the original git CLI. SourceTree is unmatched in how it makes using git so much more pleasant for when you need to do something relatively simple, but which would be quite cumbersome to do with the CLI and most other tools I've tried.
Its file status and history view is unmatched IMO. I can easily stage/unstage hunks and even lines. The whole UI is generally quite polished and pleasant to use.
It's a real shame there is not a version for linux. I've tried every other git interface under the sun and keep coming back to it. In the meantime, I tried lazygit the past weekend and I think it is one of the better TUI git tools out there, definitely better than GitUI.
On Windows I've been using TortoiseGit for over a decade now and in terms of Git power user features in a GUI I think it's unmatched.
People who defend the CLI as the only real way to use Git simply haven't used a decent GUI for it. I consider myself a very advanced Git user, but I barely know the CLI commands off the top of my head.
A GUI really makes a lot of sense for something like Git, most of the time what you want to do is "contextual' from something like a list of files to commit or a log of commits and TortoiseGit is pretty good about exposing whatever you'd need to do.
I find that with GitKraken (aside from not being free), I just don't feel in control of what I'm trying to achieve with Git.
Git Extensions seemed pretty decent and possibly a nicer GUI paradigm than TortoiseGit, but when I tried it I found TortoiseGit to offer more power to me.
One thing that does annoy me a bit about TortoiseGit is that it has this philosophy of a new Window for everything, which for most things is not a problem, but is in a couple of places. For example, to work on a repository you tend to have to use the Explorer context menu to do things. I tend to open the git log window once and leave it open, and from it I can do pretty much everything. If it had some sort of "main app" view with a tab per repository you have open that would be awesome, instead of my having to have multiple open log windows. Similarly, for commits and PRs I like to double check each file's diffs. Its UI opens each one in a new window, but if it would rather have a sub pane from the commit view I think it would work better.
I used to use SourceTree in conjunction with TortoiseGit because I liked its tabbed UI for the simple things like pulling/fetching/pushing, switching branches, but I stopped using it about 5 years ago, the Windows version of it felt neglected in that it would often crash or become very slow.
Man, those are 2 apps I haven't touched in decades. They felt novel at the time, but they just aren't as fast for me since it requires leaving my IDE which already has both CLI and visual git methods (I use intellij products)
There are two of us! I also espouse the virtues of TortiseGit any time I am able! I do take a bit of guff at work, but one feature of TG I've never seen equalled is how it handles what I call "drill-down git blame adventures". TG'a blame lets you easily keep going down through a files commit history in a way that is both intuitive and useful. My only issue with TG is that it is so Windows-focus and as I'm working more and more in Linux I will tragically need to leave it behind ;_;
Did you try magit? There's a bit of learning curve as it's built on top of Emacs, but it's entirely keyboard driven. I still have to find a workflow that it does not support.
Magit[0] is so good that I haven't felt any real need to use jj... yet. I'm sure I'll switch if it gets emacs integration of a similar level to magit, but the one I tried[1] isn't quite there yet.
[0] Well, plus git-mediate for solving conflicts
[1] https://github.com/bolivier/jj-mode.el
Same. I have not been able to find an explanation of anything jj supports that I don't have already with magit, but I am open to learning :)
I think the big thing (potentially, for me) is the ability to postpone conflict resolution during a rebase. That can be quite painful in regular old git, but git-mediate helps make that less painful in practice in my particular situation and workflow.
We'll see once better non-cli UX appears. I'm low-key excited for what could be possible in this space.
I am excited too! It is probably too much to hope, but I nonetheless am hoping that magit gets a jj backend before I have enough motivation or need to learn a new tool to do the same old stuff :D
Not who you are replying to, but I have bounced off of magit at least 3 separate times of trying it. I have been using both git and emacs for many years. Something about it just refuses to "click" with me.
FWIW, jujutsu was an improvement over git for me in about 5 minutes of using it.
There's gitu[0] if you want a similar experience without Emacs.
[0] https://github.com/altsem/gitu
Now I've got to mention Sublime Merge as my personal favorite: super fast, nice clean UI on all platforms, still maintained, single purchase license.
Big fan of sublime merge. I recommend it a lot to people who need to dip their toes in source control and want some layer of abstraction, but also want to feel like they’re connected to the underlying tool (git). Merge balances this very well.
It’s a fantastic tool, and although I’m very comfortable on the command line, I always reach for Sublime Merge
I know a lot of devs hate on Perforce (and I am no exception), but I've grown to actually really like p4merge (the Perforce merge tool) for handling conflicts.
It's a bit of an odd one, and it has a bit of a learning curve, but it's free (as in beer), relatively easy to install, and seems to work well for me. I haven't found a FOSS tool that I like as much yet.
Kdiff3 used to be great. Had a stable and outdated interface.
Now that they updated the interface I've had problems. Ch l crashes and difficulty to install as non admin.
I don't think I've actually used Kdiff3. I always assumed that it was Linux only but apparently I was objectively wrong about that. I should give it a shot.
For staging/committing I haven't found anything that I've liked more than Git Extensions' Commit view.
One of the main things I like about it is that it does _not_ auto refresh. A long time ago with SourceTree I'd have issues mixing git CLI and SoureTree because two processes would be doing things at the same time (I assume SourceTree was doing things like `git status` while I was trying to `git fetch` or something).
https://git-extensions-documentation.readthedocs.io/en/main/...
I find both Fork and Tower to be much better than SourceTree, have you only tried free tools?
I can't live without Fork. It's the one thing I miss on Linux. I have it in Wine, but it's running terribly there unfortunately.
I’ve used SourceTree for a decade, Fork is the only one I’ve switched to partially (at work).
I probably will switch back to ST even at work because I dislike:
- I want the split view of ST where I can simply see the changes and not lose the commit log.
- “see only current branch” is super useful in ST to see only the current branch’s commit log.
(Partially writing this in hopes of someone pointing out ways to do this in Fork)
You can do "see only current branch" with the little filter icon when you hover next to a branch. Although I do find myself getting lost amongst branches more easily compared to Sourcetree, I think there's some difference in how filters are combined that isn't ideal (but I can't remember specifics)
You can also go to View in the menu and click "Filter by active branch" (Ctrl+Shift+A).
Also if you, like me, wanted to blame or view history for specific files there does not seem to be a way by clicking in the GUI to achieve it. But by using Ctrl+P you get the command search and can search for "Blame" or "File history".
I use file history aaaall the time. My favourite feature in Fork.
Thank you!
Another vote for Fork here. Used to use many different UI clients, including ST and Tower but left Tower for Fork. I still add P4 Merge as my external merge tool though. It seems to have the best algorithm and often solves conflicts automatically.
SourceGit comes pretty close to it for me (same situation)
I love Tower and have paid for it for years. I can’t imagine using the git CLI now. GUIs were invented for a reason and the git CLI has terrible ergonomics and many ways to make costly mistakes.
I have dabbled in those tools. Still did not change my opinion.
It's pretty good but also really slow. I never found one better than GitX, but that was in the days before IDEs had Git support built in. Now they do it doesn't really make sense to use a separate program IMO.
These days I use VSCode and the Git Graph extension.
+1 for GitX. For some reason the most recent version in GitHub doesn't work well for me anymore, so I keep an extremely old version (Version 0.15.1964 dev (0.15.1964) in a Dropbox folder and it's my daily driver for years.
(author of the blog post here)
I think there's a learning around stability of devtools here. It takes time to get used to things, but once you do you are ultra productive. That's why IDE Git UIs are not ideal, because the graphics change so often, confusing you more than helping etc.
I got stuck to git gui / gitk for so long for this reason, I couldn't parse other UIs e.g. for diffs until I forced myself to have a less productive time to learn new UI.
I hope lazygit is stable - I think I might need to construct some stable config for visuals / colors to ensure this! (:
Have you tried the Jetbrains IDE git client yet? It hits the perfect spot for me.
Its good but actually a little slow at times. For a big repo, it feels like they're handling a few commands synchronously and it hits IDE performance, when they should really be showing some kind of async spinner and yielding so the rest of the IDE continues.
Tried it more than once, still SourceTree is easier to use.
Unfortunately the standalone one was cancelled
I've been using SourceTree for years, mainly because I like the staging experience. I've never felt good about it though, I don't know why I've put up with the terrible performance for so long. I recently stumbled upon https://github.com/sourcegit-scm/sourcegit and it's totally replaced SourceTree for me. Very similar (or better) UI/UX but much more performant.
I was using SmartGit for many years and was very happy with it, until they made it subscription based and had to switch to SourceTree. It works but I do not find it very smooth at all. It hangs every now (using MacOSX) and in general the experience is not as smooth as it was with SmartGit. I am surprised that you are saying that you haven't come across any better tool.
For a few minutes after reading this I was worried about smartgit losing its way. But it seems they actually still offer perpetual single-payment licenses, where you purchase a few years of updates, usable after update period ends.
Fellow SourceTree apologist here. It remains one of the first things I install on a new machine. I'll do simple stuff directly in the CLI, but stick with SourceTree for anything moderately complicated (as you've mentioned).
If you don't mind a TUI, I've been very much enjoying gitui - in fact, this is the second time I've recommended it recently. Adding hunks and single lines is easy, and the various commands are all visible, so it lacks the usual TUI experience of "what key do I need again?"
If you're down to try it, I actually think SmartGit is a similar style but ended up working better for the slightly more exotic things like submodules.
Fork is a great alternative to SourceTree!
There are few UI's that I hate more in the world than SourceTree. That pile of junk has cost me so many hours of life trying to support the developers in fixing a thousand weird issues.
No, please throw SourceTree into the garbage can.
What exactly were the problems? I have been using it since like forever and have not run into any issues at all. Granted, like I said, I don't use it for any hard-core stuff.
I've used SourceTree for years, and for advanced flows, with an external tool for diff. Never failed me from the base, squash, orphans, forks,...
This has been my experience as well and I will probably end up paying for a tool because the free ones just don't work smoothly.
Do you use the Mac or Windows version?
The Mac version
The Windows version is decent too. They seem to be at least partly different code bases, which is nice in some respects, but does mean they're not quite the same. The Mac version is less good about doing git submodule update when required, and sometimes the side panel state can be wrong; the Windows version seems to occasionally forget the state of the delete after applying option when doing git stash pop.
Despite having some annoying aspects, it is (as if you even needed to ask) still better than using the command line, and, importantly, has yet to annoy me enough to actually switch to something else. Though as an Emacs fan I do have Magit on my list.
The less I use git directly, the more convinced I am that git is an absolutely awful interface to git repositories. I have been using jj for about two years now, and I literally cannot imagine going back to using the git cli. I have not used lazygit, but if you find it interesting, I say please go for it.
The please is because I am tired of fixing issues created by people being confused by git. Just use anything else than the git cli, it's probably better.
I have tried jj several times but I feel like it slows me down significantly because I can’t grok the workflow. I like to do a bunch of changes then quickly select them in my editor and commit them, breaking them up into different commits to keep them organized. With jj’s lack of editor integration, I don’t know how to do this with the cli alone so I end up with bigger messier commits.
You want "jj commit -i". You'll get an interface that lets you choose files, chunks, or lines to commit.
Or the shorthand: jj ci -i
Or if you don't care to set a commit message just yet: jj split -i
Or if you want to defer making sure each commit has the right content until later, just use jj new, and then later use jj squash and jj split to make the commits have sensible changes, and jj desc to set the descriptions.
Sold!
I'm trying jj. I've seen enough mentions now. I've never read anything about it.
I hope it's compatible with git.
The compatibility with git is the whole reason it's so popular (just run `jj git init --colocate` in your git repo). You can use it without forcing your collaborators to switch from git and you can use it will a git forges as well.
I don't think you need `--colocate` any more, and maybe you don't even need `git`? I tried `jj init` in a git repo the other day and it did create a colocated jj repo, as far as I could see.
Not sure on `jj init`, but yeah colocation is default as of I believe 0.34
With git I can stage lines right in my IDE, no messing around in shitty TUIs.
https://jj-vcs.github.io/jj/latest/config/
ctrl+f "tool"
This exact thing is quite literally one of jj’s flagship features: `jj split`.
In JJ you make a bunch of changes and then you split the commit into multiple commits.
> This site was paused as it reached its usage limits.
https://web.archive.org/web/20251111071832/https://www.bwplo...
Should be now fixed, 6k views was too much for a free tier! Thanks for archive link
You should try cloudflare. 6k views is nothing on the free tier. Shocking to see your website taken down for 6k views
Btw it's down again
Makes sense, thanks!
Wait, no one mentions the default JetBrains IDE git UI? I mean, I get it if you're working from another IDE/text editor that doesn't have good git UI support out of the box, but JB's git UI is reasonably good enough that I don't want anything else.
Things that I use (and I like): 1. quick checkout to another branch and automatically stash and unstash your local changes; when I just need to inspect code elsewhere I find it really useful. My changes are small so I can always remember to stash them later; 2. compare branch/commit etc via UI; again I know you can do that in git diff, but then you would need to know the command and the commit SHA to compare; in UI it comes in really handy, just select the branch or commits you want to compare and that's it. I've seen my coworkers trying to come up with the command and I just say: use IDE and a couple of clicks they got it working. 3. filter commits by user and by folder.
(author of the blog here)
That's a great point. I should have mention the IDE Git UIs, def a nice option and sounds like the JB one works well for you!
I do use it heavily for "annotating git blame"!
I've never consider using JB Git UI fully mainly because of the point made earlier, so stability (https://news.ycombinator.com/item?id=45898089). Once you learn, especially visually, you don't want cosmetic changes. IDEs change yearly to stay "consistent".
Another point is portability. E.g. I didn't want to pay for personal use of JB (so rare case), so I have to use different IDE. Separate tools (especially free and OSS) is a big advantage. Not mentioning ability to use it on remote shells or different machines!
lazy git offers 1, but 2 and 3 points are interesting. Wonder if there's an easy way to compare commits and filter commits by user and folder in lazygit. (:
EDIT: Actually, I also use JB for conflict resolutions ;P so not entirely 100% lazygit flow.
I don't think JB UIs been changing that much, albeit I haven't been working in the industry long enough. I think the last major UI redo was like 2,3 years ago and most of it is to make UI more compact, and I definitely like it. That being said YMMV.
IMHO another good thing of using JB IDE git UI (especially in a corporate setting) instead of using another software is that everyone has the IDE so it's easier to collaborate. Imagine if you're helping a junior member debug their local branch and they don't have lazy git installed.
The diffs are the biggest reason I use it (beside the 3-way diff, I can't live without: blame, optimize imports, all the editor functions inside the diff, diff files/commits/branches).
Beyond that: separating into change lists (staging changes by line inside a file) and the graphical presentation and filtering of the commit history (highlighting what commits are in/out of your branch, show the git history of a section or line of code, show repo files at a commit)
100%. One big benefit of IDE integration is that it’s the same editor. Same keybindings, same syntax highlighting, etc.
I still prefer tig[1]. It has probably less features, but also a less cluttered UI and slightly faster interface.
But the main use I get from it is for incremental index adding, so maybe not as much as OP.
[1] https://jonas.github.io/tig/
Me too, it’s been my tool of choice for staging hunks for more than 15 years now.
For that, I use git-cola... for some reason. Even though I live in the terminal.
Oh, I didn't know it. It looks pretty useful, but it requires more mouse usage than I'd like and its window is not very well suited for tiled window managers straight out of the box.
Yeah I have a rule in my i3 config so it gets focused and fullscreen. It does require mouse usage, which is why I wonder why I like it over say, lazygit. I may switch, but yeah, thought one should know of its existence, it is a cool piece of software, too.
A large percentage of git users are unaware of git-absorb (https://github.com/tummychow/git-absorb). This complements just about any git flow, vastly reducing the pain of realising you want to amend your staged changes into multiple commits. This sits well alongside many TUIs and other tools, most of which do not offer any similar capability.
I gave it a try a few months ago, and wasn't impressed. About a quarter of the time it got confused about the commit it should squash into, and left the repo in a half-applied state. This inconsistency was enough for me to not trust it when it did work, so I stopped using it.
Honestly, it's too much magic for my taste. And, really, it's not much manual work to create fixup commits for the right commit anyway.
I see the usefulness. But my client is magit, and committing and rebasing are so quick that this will reduce perhaps 30 seconds to one minute to my workflow. And I do not like most rust tools, because they're too dependency heavy.
Definitely. The instant fixup feature is just three keystrokes away (s c F). The only thing this helps is when you don't want to spend the extra brain cycles to figure out which commit to fixup on.
The task that absorb speeds up is finding the commit where each hunk was last changed. The actual committing and rebaseing is still basically the same.
Git blame using `M-x vc-annotate` with Emacs. But If I have a clean PR that usually means one to three commits (If it's not a big refactoring). So the whole point become moot. In magit, if you create a fixup or a squash commit, it will present you with the log to select the target.
Yes, or magit-blame, but if you still have multiple commits in your history that you are working on, and you need to break up the current changes in a bunch of instant fixups, figuring out which one is the right one can be a bit time consuming. I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.
> I'm not convinced that automatically amending to the last commit that touched that line is safe, but I'm willing to try git-absorb.
It is not, but git absorb only produces fixup commits, you can still change what they change in the autosquash step.
It's in the GNU/Debian repo and I guess in a lot of other distros as well.
to me this appears to be trading off a valid change log for neat naming ... i dont see why rewriting history is ever a good idea
I find it quite hard to follow PRs when there is a lot of rebasing. I don't really find separate non-time-based commits useful.
So I agree but unfortunately it's the norm and policy for some clients.
Git-absord by default doesn't squash the fixups though, it creates new ones with special tags for easy rebasing later.
People often avoid it because of the name, but Github desktop is pretty amazing. It works great with all git repos (including ones not on Github), and makes it super easy to amend commits and cherry-pick files/lines to include. Everything has handy names, and all the complex operations have text explaining what they do.
GH Desktop's merging, conflict stuff, and (lack of) graph leave much to be desired, but it's already 1000 times better than the git cli. Whenever I have someone who hasn't used git before joining a project, I always get them to use GH Desktop - it's easier for them to understand what's happening, and reduces the messes they cause compared to running random git commands from stack overflow.
> it's already 1000 times better than the git cli
Sure, but that's such a low bar, that everything clears it.
> GH Desktop's merging, conflict stuff, and (lack of) graph leave much to be desired
I think that's more of the reason why people avoid it.
Seconding GHD. They have added features very slowly, very thoughtfully; HN tends towards experts (or at least people who think they are). I am aware that I'm NOT good with git. I will never do anything that has "hard" or "rebase" in it without spending 20 minutes making sure its what I want to do. Unfortunately I have seen way too many semi junior engineers who think they're git lords who force push bad histories and ruin our git repo. I tend to suggest strongly that people should use github desktop if they are in my team though very few people take up that suggestion :)
It's very hard to destroy things with git. Every action is stored with the reflog. Then also, in a team setting, you should want the copy on the forge to have protected branches so that no one push (or force push) on them.
Something not mentioned in the article which has changed the way I interact with git repos (and the reason I will never not use LazyVim until something better comes along) is just how well the system plays with tmux floating panes.
I have it so that anytime I press ctrl-g in a git repo, I open a floating tmux pane in my current working directory. This might sound "whatever", but it means I don't have to actually be inside neovim or "switch" to the LazyGit UI. It just overlays it on top of whatever I'm doing at the moment in the terminal.
Makes for the most fluid, streamlined git experience ever if you primarily live in the terminal.
Indeed! I just found out about tmux display-popup recently.
Then, in tmux:Pretty much my config exactly. I make mine a bit bigger tho:
(author of the blog post here)
Oh yes, I use lazygit as a separate binary (brew installed) from separate terminal shell all the time. No need for nvim!
Great to hear you can neatly configure similar UX (popup) with tmux!
Personally I just couldn't see all the extra layers as comfortable tools. It's a very rare thing that I need to see branches, relation between them etc. Using cli has always been the most reliable and simple way for me.The only git tool I need apart from cli is a convenient conflict resolver.
> It's a very rare thing that I need to see branches, relation between them etc.
And when you do, git log has "--graph --oneline" to do just that.
I have an extended version in a bash function because I do do it often and it's much easier/faster than opening a separate tool.
Yeah: Most use-cases for me split into:
1. Choosing what to commit and committing it, fixups, autosquash
2. Conflict resolution and history investigation
It's very rare I've wanted a separate tool for the first, and the second calls for a GUI tool.
Lazygit is great, I use it all the time for straight forward git-fu.
I do recommend turning off force push (there is an option), as it's easy to fat finger and leads to a whole lot of heartache.
But if you do any advanced work that involves merging a complex codebase across multiple branches, with generated code and multiple languages; and having to manage your load of conflicts, I find Fork[1] (the free version does fine) still takes the cake for that, as the clarity and lack of keyboard bindings, is essential; to make good, conscious decisions.
[1] https://git-fork.com
To be clear, there isn’t a free version. There’s a cost-less download that’s meant for evaluation purposes, with the goal of paying them if you like it and find yourself using it long-term.
Given that Fork is a two-person family company that’s somehow managed to make the best Git client in the world for a single reasonable price with free updates and no subscription, I’d suggest that it’s worth paying for to keep their business sustainable.
--force-with-lease should be safer.
force with lease has been used in lazgit already AFAIK, see: https://github.com/jesseduffield/lazygit/discussions/4068#di...
"it is our policy that if something is already configurable in git, we don't add the same option again in lazygit"
This seems a very solid rule.
I just took lazygit for a spin:
In general, the tool looks cool. It also looks like it takes time to learn; but if you find it useful, it's probably worth it taking the time to learn.
There were two blockers for me:
1: I can't free-form select text with a mouse like a can in a terminal. (I honestly haven't used a TUI since the 1990s.) I frequently copy bits of branch names from the terminal, so this was a big deal for me. There is a way to "disable" the mouse in lazygit, which then allows copy & paste; but as I prefer to learn a program with point & click, it's a non-starter for me.
2: A lot of this functionality is built into Visual Studio for me. I use a mix of Visual Studio's point & click with git, and then the git command-line: Whichever is easiest for the specific task I'm doing. It just takes a bit more exploration in Visual Studio to find this functionality, as opposed to it being front and center when starting lazygit.
(author of the blog post here)
Fully agree!
1. Yes, it's been a frustration initially, but it has a nice benefit - it forces you to use native features (e.g. patch based copy/reset). Apparently it's on the radar, but not implemented yet: https://github.com/jesseduffield/lazygit/issues/4365#issueco...
2. Yes, see https://news.ycombinator.com/item?id=45898167 discussion. Using IDE is great if all your machines has this IDE installed (and GUI in general). The stability (graphical layout) is likely changing often though.
If you run it in a tmux, you can do "set -g mouse on" in your config and then just select whatever you want.
TMux doesn't run on Windows. (Kinda implied, because I stated I use Visual Studio.)
"git gui" is not just a wrapper for commands; it has usefully different workflows.
For instance, you can visually select a range of lines in a file, and stage those lines.
This is much easier than doing "git add --patch" and using edit, where you are deleting unwanted lines starting with +, turning - lines into context and whatnot.
I have found it useful to fire up "git gui" during rebase workflows with conflicts. It helps with the "git add" commands you would have to do to add conflict-resolved files into the patch and whatnot.
> For instance, you can visually select a range of lines in a file, and stage those lines.
Isn't this the standard for every Git GUI? Are there people who use a GUI that can't do that?
No idea; I don't know every git gui; I'm talking about that Tcl/Tk thing that is literally run with "git gui".
It would be pretty pointless to go out of the way to use something that doesn't come from the git project, yet is less capable (unless it had some overriding killer feature for the sole sake of which it was invoked).
(author of the blog post here)
What! I was git gui user for decade and didn't notice this feature =D But yea, git gui is amazing overall. I don't think it's maintained anymore though.
BTW lazygit offers that too and it's a bit easier to discover and use (e.g. you don't need a mouse).
And I'm still just using tig [0]. I miss a few of the more fancy features but it's simple and reliable and compiles everywhere I need.
[0] https://jonas.github.io/tig/
Yes! Godspeed to lazygit!
Really happy to see it featured here, I became a convert couple of years ago after switching to Astronvim (lazyvim is bundled with it).
No one's mentioned Gitu yet but it's a pretty nice client https://github.com/altsem/gitu
Am I the only one who simply doesn't mind Git's CLI?
Sure, it's rough around the edges, but I know those edges well. I sometimes do need to look up how to do something, but those cases are rare. Over the years I've accumulated about a dozen shell aliases and a modest `.gitconfig`, and along with a couple of helper tools[1][2], I can do 90% of what I need Git for in seconds. I truly don't need a fancy TUI, GUI, or any wrappers around Git. Git itself is fine.
I tried Magit a few times, and even though Emacs is my main editor, I couldn't get used to it. It forces the user into doing things the "Magit way", and I'd rather not.
I don't understand the push to replace Git's porcelain with something shinier. If, and when, a better VCS comes along that truly feels like the next step forward, I'll give it a try. In the meantime, Git does the job I need.
[1]: https://github.com/mroth/scmpuff
[2]: https://github.com/dandavison/delta
I can use the CLI, but magit is mostly CLI on steroids. All the information you could have accessed through the cli is quickly available, and they are active objects, meaning subsequent commands will take that into account. Any mutation is also available through quick keybindings as well.
The one thing that I truly like about Magit, and the builtin vc-mode, is that I can focus for a couple of hours on coding, then quickly create a serie of commits to capture that work. Like doing line art after sketching. I like when administrative work (filing patches under commits) is isolated from creative work (solving problems and designing practical solutions).
No - unless you took away my gitconfig, which is pretty big at this point. Though I guess that's mostly a time-saver. Even so, I've found most of the GUI tools to be confusing because it's hard to tell what they're actually doing under the hood.
I do use sublime merge at times though now - it's nice for [un]staging individual lines and for looking at some diffs. I also like git-foresta[1] more than log sometimes. I'll have to check out scmpuff - it should be easier than going through a patch add.
[1]: https://github.com/takaaki-kasai/git-foresta
I do not mind the Git CLI, and I just carry around my alises. I also built a tool to make it even more powerful and integrate with issue trackers: https://pypi.org/project/gibr/
I completely agree, and I would add that in just about any dev role beyond being a junior it's so common to need to work efficiently without much of a dev environment anyway.
There's just no point in fighting this battle. I will admit it's sometimes nice to have fancy tools, but they're just that. I don't get the need to make a hobby out of it when there's so much other stuff to do.
> Am I the only one who simply doesn't mind Git's CLI?
No, but by definition, Git's CLI doesn't scale for complex use cases. No one would voluntarily use the CLI for doing a complex 3-way merge if they could avoid it.
Due to the complexity of Git's interface, it's too easy to make a mistake using the CLI. I get we don't use most of the options most of the time, but when you need them, they're not exactly discoverable.
git help commit is over 4,000 words!> No, but by definition, Git's CLI doesn't scale for complex use cases.
How so? A CLI is where you run commands and things happen. Sometimes those things can be "complex", whatever your definition of that may be.
> No one would voluntarily use the CLI for doing a complex 3-way merge if they could avoid it.
And nobody does...? A manual merge is done in an editor or a standalone tool, not the CLI.
> Due to the complexity of Git's interface, it's too easy to make a mistake using the CLI.
Well, Git's UI can be intimidating for a newcomer, but once they're acquainted with the dozen or so commands they might need every day, they can define aliases for them, and mistakes are no more likely than with any TUI or GUI wrapper. Git by design gives full control to the user, so mistakes can happen, but this is no different than with most Linux tools. And if safety is a concern, then whatever hand holding a TUI or GUI does, the same can be implemented in a shell script.
> git commit alone has 40+ options
So? You would prefer less options? Less commands? Less flexibility?
Just look up what you need to do and how to do it, and stick it in an alias. Now you have a clean command purpose built for your use case, and you can ignore anything you don't use.
Or, you can use a fancy TUI/GUI wrapper that "simplifies" this interface for you, and then when you need to do something that the wrapper UI doesn't allow you to do, have to fall back to the original UI. I'd rather familiarize myself with the original UI, create the aliases and helpers that work best for my workflow, and not have to depend on someone else's idea of how I should use Git, or any other tool.
There is a new VCS that is a step forward (while being compatible with git). It’s called jujutsu.
Yeah, I disagree.
I've read the Jujutsu documentation and a lot of praises for it, and its most compelling feature is a simpler UI compared to Git. There have been other VCS tools with arguably better UIs and feature sets than Git (Mercurial, Fossil), and yet they haven't gained traction, for better or worse. The only reason jj is having more momentum is because of its compatibility with Git, which was a smart decision by its developers.
A better UI is not something I would consider a next step for a VCS tool. I can do that myself with my shell and small helper tools. Whereas features like semantic and binary diffing would be compelling generational improvements over Git. I know these can technically be tacked on to Git itself, but a VCS built for them would be able to do things Git simply can't. These are just two I can think of, but a next generation tool would be evident without requiring much explanation. Just like DVCSs were over the previous generation of tools.
jj is not just a simpler UI. Its rebase is fundamentally more powerful than git, it has things like the operation log, first class conflicts, etc… that git doesn’t have.
VS Code is free, cross-platform, many people already use it, and has a very good GUI interface for git.
It can easily do all the common workflows.
I mainly use the CLI but if I already have a project open in VS Code I'll just do it in the GUI because it's actually faster in many cases and sometimes a bit more intuitive.
But then you have to use VSCode, and that's never a good thing.
why is that never not a good thing to you?
(author of the blog post)
Yes, I think it's a reasonable option if you use vscode on all your dev machines.
We discussed this in another thread: https://news.ycombinator.com/item?id=45898167
Lazygit, WezTerm, NeoVim, Yazi (TUI file manager) are a fantastic combination! I have a tmuxniator config file for every project I work on. And open a tab in WezTerm, run „mx projectname“, it opens a split for Yazi, one for Lazygit, one for neovim, and one for my agentic coding tool. Lovely setup, super fast, all in the terminal.
I'd recommend lazydocker, from the same author IIRC. Awesome TUI.
Top things I love with lazygit:
- Patching with <C-p>, easily the best feature. With a few keystrokes I can revert or move lines from any commit.
- Amend any commit directly instead of fixup + rebase.
- Single line hunk manipulation.
- Integration with difftastic for semantic diffs.
I have some bash_aliases and scripts.
The king of all alias is fixup, which commits everything and fixes up the commit with the previous one.
Another script just goes over the changes and allows me to add/skip/restore.
Then I can pipe the log to another script that will analyze tags and tell me what is not yet in prod.
cli is hard... but it composes. I want to know that CLI as well as possible. And I don't want to start from scratch each few years with a new UI / concept.
Off-topic: but the README of lazygit is awful with all those sponsors at the top. I hope Github comes up with a better way to list sponsors that favors developers and allows them to exclude them from the README.
https://github.com/jesseduffield/lazygit
I use lazygit in neovim through the snacks plugin: https://github.com/folke/snacks.nvim/blob/main/docs/lazygit.... It works really nicely, without any fuss.
If you're on Windows and you like the git CLI, try GitExtensions. It maps pretty much 1-to-1 to the git CLI and is still discoverable.
I'm the "git guy" at every place I work and I don't touch the git CLI. Been using Magit for 15 years now. I just don't think a CLI is a good interface for state mutation.
CLIs are perfect for functional interfaces, like grep, sed etc. But I think they are very hard to get right when side effects are in play. Really basic things like mkdir and rm are ok, but when you have enormously powerful things like git rebase I find it difficult to keep track of what's going on.
I wonder what a more functional Unix would look like... Instead of mkdir just write to any path, instead of rm just overwrite a path with nothing, maybe we'd accept that mv would be implemented as "porcelain". The balance I think is keeping a lid on how complex that porcelain can become, and git has way overstepped the mark. So I prefer GUI/TUI interfaces for mutation, and Emacs is the best there is for building those.
Maybe I missed it but I couldn't find where to install it from and autocomplete doesn't resolve to a debian package either...
https://github.com/jesseduffield/lazygit?tab=readme-ov-file#...
So with a newer non-LTS ubuntu you can just apt install lazygit, with 24.04 it's
``` LAZYGIT_VERSION=$(curl -s "https://api.github.com/repos/jesseduffield/lazygit/releases/..." | \grep -Po '"tag_name": "v\K[^"]') curl -Lo lazygit.tar.gz "https://github.com/jesseduffield/lazygit/releases/download/v..." tar xf lazygit.tar.gz lazygit sudo install lazygit -D -t /usr/local/bin/ ```
For folks looking for a GUI tool, SourceGit is quite nice.
Written in C#, cross-platform (I have only used it on linux) and a cleanly-designed conventional ui that doesn't aspire to radically alter your workflow.
https://github.com/sourcegit-scm/sourcegit
In the example of how they were removing specific lines from the previous commit, git gui had a way to do that instead of copying the diff lines and manually editing them back into the code:
git gui → Amend Last Commit → (select lines from a file in the Staged Changes area) → Unstage Lines From Commit → Commit
I still think it's the perfect does-just-enough GUI when the main thing you want is to visually craft commits.
I've found the built in gitk is pretty good for some GUI tasks. If I want to view the sate of some file at a given commit, it's easier to navigate using that rather than going through git log, find and copy the commit, git show, paste, copy the file path. GitHub desktop didn't seem to have this feature last I checked, even though the GitHub web viewer does.
The git integration in VS Code has gotten really good lately. It has the commit graph, with cherry picking, worktrees, stashes and a very nicely integrated merge editor and rebasing, along with all the common commands. Also staging individual sections and lines visually, which I use daily
I recently started working on a repo which historically had 100+ parallel branches. I've been jumping between a few tools recently trying to find something which handles browsing these sanely - I always liked browsing graphs, but the sheer amount of branches ruins most of them.
Currently the best workflow I've worked out is just a plain
Followed by showing the specific commits. But this doesn't work so well with MRs that touched many files across different dirs. Anyone have suggestions for tools that might handle this better?Perhaps I am a simpleton, but Tim Popes vim-fugitive has always been enough for me.
I'm stuck on a mac these days and I miss Git Extensions, my favorite Windows git UI
There are several really good Git clients for macOS:
1. Fork: https://git-fork.com
2. Kaleidoscope: https://kaleidoscope.app
3. GitUp: https://gitup.co
4. Tower: https://www.git-tower.com/mac
SourceTree also isn't too shabby, though the interface is slightly different than the Windows version (for whatever reason).
Git Tower is the best native UI client
After a short stint when I had to do dozens of small edits to files, this became something I use every day (and I am the sort of person who types git commands by choice, even inside VS Code…)
I was first convinced to try Lazygit after reading https://jesseduffield.com/Lazygit-5-Years-On/#weighing-in-on... (written by Lazygit's creator).
Haven't regretted it at all; the tool is a pleasure to use due to its great design decisions. Contributing back to the codebase is also quite straightforward.
My current setup is just a few alias commands and I use gitin instead of "git log". I really wish that tool was still in development because it provides a really nice minimalist design for exploring git repos: https://github.com/isacikgoz/gitin
After years of using git I got back to svn.
Svn has one great feature, you can checkout (clone) repo partially.
This way I can keep all my experiments in a single remote repo and easily pull any part of any project locally wherever I want.
I don't really care about branching in svn. If I want to try variants of some code I still use git with multiple branches.
I'm not sure what I would prefer for a team project. I'm sure svn got decent merging.
I think git can do partial checkout these days, you can even filter which parts of the history to store locally, like download all commits, but not the file content for them, and dynamically load them when needed.
> After years of using git I got back to svn
You get the best of both worlds--a sane set of commands and a distributed version control system--by using Mercurial [1].
Checking Status: SVN: svn status Mercurial: hg status
Adding Files: SVN: svn add <filename> Mercurial: hg add <filename>
Committing Changes: SVN: svn commit -m "Commit message" (commits changes directly to the central repository) Mercurial: hg commit -m "Commit message" (commits changes to the local repository) and hg push (sends local commits to a remote repository)
Deleting/Removing Files: SVN: svn delete <filename> or svn remove <filename> Mercurial: hg remove <filename> or hg rm <filename>
Viewing History: SVN: svn log Mercurial: hg log
Viewing Differences: SVN: svn diff Mercurial: hg diff
Branching: SVN: svn copy <source_URL> <destination_URL> (creates a branch by copying a directory in the repository) Mercurial: hg branch <branchname> (creates a new named branch within the repository)
Reverting Changes: SVN: svn revert <filename> (reverts local modifications) or svn merge -r <revision>:<revision> <URL> (for more complex reverts) Mercurial: hg revert <filename> (reverts local modifications) or hg backout <changeset> (to undo a specific commit)
[1]: https://www.mercurial-scm.org
And partial checkout?
Sure.
If anyone's curious it's achievable through sparse and narrow (NarrowHG) extensions to Mercurial.
I must try it out.
One really nice thing about a distributed version control system is that it lets me as a developer make commits to track my work without having to push them to a central location and pollute the global commit history of the repository. I can modify my commit history (to clean it up and remove all of my failed experiments, for example) before I publish it, so to speak. Or I can completely remove my commits without publishing at all if what I was trying didn't pan out.
> I'm sure svn got decent merging.
That's definitely not my experience. SVN has merging, but I've found it extremely frustrating in a team context.
When did you experience it last time? I remember it being bad, but it was before git was created.
Last year, unfortunately. Most modern utilities, even svn-to-git migration utilities, have been abandoned now that git has become the de-facto standard and everyone who can reasonably be expected to switch to git has done so already.
Lazygit is the only way I review PRs these days because it is trivial to step through a file commit by commit when that is necessary (which maybe says something about the quality of the PRs I'm reviewing...). They also won me over by using Legend of the Galactic Heroes references in the github readme gifs.
Glad somebody got the reference!
Maybe one day, but after almost 15 years of using handful of git aliases I just can’t switch to anything else.
Anyone used GitKraken?
I haven’t, but for reasons, I’m interested to hear about your experience with it.
Gitkraken is the best, and I can't believe anyone would voluntarily use Sourcetree over it.
I've used gitkraken for over 9 years and it's great for both newbies and pros.
It completely solves the problem with new or intermediate devs, who are not used to working in a sizable team, constantly needing hand-holding.
Lots of people resist adopting it at first, but not one has regretted it so far. It usually goes like this:
1. "No I won't use it, the terminal is better"
2. Mess up
3. Finally give gitkraken a serious try
4. Realize they didn't really know git
Been using gitkraken for ages and still like it, but they do make it harder and harder to like every update. The enshittification seems to have started and every update seems to bring more and more ai features, and pushing more ”cloud” features as well
Intellij is so much better than command line now, I can't imagine going back.
Well to be fair, anything is better than the CLI (unless you are a masochist ;)
I prefer to just voice to text to an ai and have it do git operations for me. Either that or ctrl-r seem to be a great set of UI
Simple, Clean, CLI, Vim navigation
Lazy git checks off a lot of boxes. Easy tool to adopt to speed up and simplify your git workflow
For some reason it shows half the text in English and half in Dutch
I use lazygit when I want to stage specific lines rather than an entire file.
I use the CLI git to stage lines. Use `git add -p` to add only the lines you want to commit with your chosen text editor.
This is literally the only way I stage file changes. I want to see and approve everything that goes in.
lazygit is too slow at patching big files. If performance ever improves I'll come back from fugitive.
lazygit rules!
the only good git GUI that exists is Fork. Unfortunately, it doesn't run natively on Linux, although some people have had luck running it under Wine.
I found lazygit specifically so bad to the point that I was better off typing in git commands into the terminal manually like some sort of caveman. Somehow, lazygit has found a way to make git even more confusing and user hostile than it already is, which is a significant achievement.
Using it was a harsh reminder of what people running emacs or vim for the first time have to go through.
This idiotic ui paradigm where you have to actively learn to use what should be simple software by memorizing commands and shortcuts needs to die off. It's mind bogglingly inefficient and disrespectful of user's time.
Just think about it - I've literally never had to open Fork's manual (I am not even sure it has one) whereas in lazygit it is utterly impossible to do the most basic things without referring to the manual. Why do we collectively keep tolerating these shitty tools?
Wow, $60! It had better be really, really good for that price.
I managed to get on fine with lazygit during a quick trial this morning. It actually doesn't have a manual (`man lazygit`: `No manual entry for lazygit`) but I found the contextual help (e.g. press ?) useful.
Tower is also very good. Probably just due to having used it more, I prefer it over Fork, but I can get by if I have to use a computer not licensed for Tower.
As much as I heartily disagree with most of what you wrote - and seeing all the downvotes, I'm not the only one - there is a nugget of truth in what you wrote, which answers a lot of your complaints.
"Using it was a harsh reminder of what people running emacs or vim for the first time have to go through."
The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
Mouse-driven tools like VS Code don't demand that the user learns them. Keyboard shortcuts there are optional, since practically everything is in a menu or a UI that can be moused to. This adds on seconds per interaction, adding up quickly over time.
+And the "learning" for these tools can be shortened dramatically by keeping a printed-out cheatsheet. For Vim this can be a huge lifesaver; I made one for magit as well, back before I switched full-time to JJ.
> The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
I have never been rate-limited by my keyboard input speed. I have lost many minutes of time daily looking up cheatsheets for terminal tools that I use occasionally.
Ironically, when I see what impact AI has had on my programming, the biggest has been in saving me time crafting command line invocations instead of browsing <tool> --help and man <tool>.
The speed change you see is not due to raw input speed, but do to eliminating a context switch in the brain. I thinking I want to see X and already seeing it on the screen.
> Mouse-driven tools like VS Code don't demand that the user learns them.
Honestly, I found the barrier to entry way lower with lazygit than with vscode.
I realise I'm not adding anything useful to this discussion. I tried to start VSCode so that I could evaluate it and, maybe, add some info. as to why I find it more difficult to get into, but it just crashes now :shrug:
> The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly more efficient experience once the learning is done+.
This is simply not true and I say this as a life long vim user. The only reason I have vim mode enabled in all the editors that support it, is the fact that it's immensely difficult to retrain muscle memory accumulated from a decade+ time sunk in that editor. Nothing about vim or any of these other tools being keyboard driven, make me more productive in a way that matters.
> Mouse-driven tools like VS Code don't demand that the user learns them.
Good. That's how all software should be. It's a means to an end, not the center of the universe. The whole reason for bringing a UI layer into all of this in the first place is freeing up my brain from having to deal with git's bullshit.
> Keyboard shortcuts there are optional, since practically everything is in a menu or a UI that can be moused to.
The shortcuts are still there if you care to learn them - it should absolutely not be a prerequisite.
> +And the "learning" for these tools can be shortened dramatically by keeping a printed-out cheatsheet.
Or, I could use some actually well designed software and save myself some printer ink :-)
> Or, I could use some actually well designed software and save myself some printer ink :-)
Or, you could use some well-designed and self-documenting software. Too bad there's not much of that besides Emacs - on the other hand, Emacs and occasionally a browser cover most of my computering needs...
Considering that Emacs has "eww", you could do all of your computing in Emacs
Good joke