I was in the "CLI git only" camp for a long time, because I found many of the points the article addresses were true for other attempted UIs on top of git: they obscured what was going on, tried to impose metaphors that didn't really fit with how git worked and thus made operations potentially dangerous, and were severely limited in what they could do.<p>Nowadays, lazygit is my main interface to git - it's intuitive, addresses the complexity of git head-on, and doesn't even assume you'll remember its shortcuts constantly (except for ']' for some reason, which isn't shown in the bottom shortcuts row). I found that I had to handle other git porcelain (i.e. UIs) really like porcelain, constantly afraid of breaking something. lazygit in constrast just feels like someone made a visual representation of git's design and allowed you to interact with it.
> Fossil is a recent git alternative<p>It’s almost as old as git. Fossil has been around since 2006, while git was born in 2005.<p>> Merge conflicts aren’t first class<p>Another DVCS where conflicts are first class is Pijul. It also has a solid theoretical foundation, which it inherited (and expanded upon) from its predecessor, Darcs.
I think I may have said this before but:<p>> Warp: a terminal emulator whose killer feature is allowing you to edit your command as if you were in vscode/sublime<p>I exhort anyone interested in this feature to enable vi mode for your shell; zsh, bash, and ksh all support it. Readline also supports it, which will let you use it in CLIs like REPLs and psql. It is <i>glorious</i>.
> When I create a commit, several things happen:<p>> my staged files disappear from my list of file changes<p>> a new commit is appended to my git log<p>> my branch ends up with a new head commit, diverging from its upstream<p>> If you create a commit from the command line, you see none of this.<p>Sure, if you're not using an addon like powerline-shell. If you do, all of those are immediately obvious.<p>I'd argue it's less "commandline bad" and more "<i>stock</i> commandline bad."
I would have thought most discussions around "UI vs CLI" are more about "GUI vs CLI".<p>Keyboard-driven git UI's which aren't GUI are relatively niche. (I can think of magit, tig, and lazygit).<p>Whereas, a git beginner may be more likely to start using git with a GUI, e.g. the git panel in VSCode, or something like GitKraken.
> In fact I’d love to pit a CLI veteran against a UI veteran in a contrived gauntlet of git challenges and see who reaches the finish line first. You could also determine the speed of light for each approach i.e. the minimum number of keypresses required to perform the action and then see which approach wins. Even if you had a thousand aliases, I still think a keyboard-centric UI (with good git API coverage) would win.<p>If they're faster than CLI it's because they are also CLI experts who have an ideological mission. Nobody cares about this situation. Overall the CLI is still faster in the majority of cases at most workplaces.
I've been primarily using SourceTree since way back when it was an indie app, and have continued to do so because the alternatives just don't present the information I want in a convenient way.<p>Lazygit is the only other UI I've seen which presents all the relevant information without having to tediously click/scroll through a lot of clutter.
I use lazygit every day, so much I just type lz.<p>It's an awesome project, highly recommend.<p>If anything I'd just recommend you set your own shortcuts to avoid doing an unearthly amount of damage, typing keys as shortcuts when you're thinking you're typing a commit message :)
I learned about lazygit recently from it's integration with lazyvim. The nice thing about TUIs is how it works anywhere - if I am doing work on WSL or a remote machine I can use the same tool with no issues!
> I’m torn on how to interpret these results: being in the top 300 in Homebrew is pretty cool, but 15k installs feels lower than I would expect for that ranking. On the other hand, having almost 1 in 20 Arch Linux users using Lazygit seems huge.<p>Doesn't the conclusion seem obvious? Most devs aren't Apple fans.
Related:<p><i>Lazygit: Simple terminal UI for Git commands</i> - <a href="https://news.ycombinator.com/item?id=36782018">https://news.ycombinator.com/item?id=36782018</a> - July 2023 (79 comments)<p><i>Lazygit: A simple terminal UI for Git commands</i> - <a href="https://news.ycombinator.com/item?id=29394162">https://news.ycombinator.com/item?id=29394162</a> - Nov 2021 (141 comments)<p><i>Show HN: I made a tool that made me faster at Git</i> - <a href="https://news.ycombinator.com/item?id=17689014">https://news.ycombinator.com/item?id=17689014</a> - Aug 2018 (229 comments)
I’m disappointed at how much value some place in the +1 count on a proprietary code forge that the writer suggests not even taking charge & having your own dedicated page & embedding call-to-actions in the UI itself. I can’t blame them for wanting to market so hard & in this fashion (tho not big on the join-the-Discord callout at the end), but I don’t like how much value folks are putting into a metric that’s both easy to game & part of the keep-you-on-the-platform social media scheme that Microsoft GitHub has a lot of developers trapped in.
> The reasons for the deficiencies in human-machine interaction are numerous. Some come from the limitations of today's technology. Some come from self-imposed restrictions by the designers, often to hold down cost. But most of the problems come from a complete lack of understanding of the design principles necessary for effective human-machine interaction. Why this deficiency? Because much of the design is done by engineers who are experts in technology but limited in their understanding of people. "We are people ourselves" they think, "so we understand people." But in fact, we humans are amazingly complex. Those who have not studied human behavior often think it is pretty simple. Engineers, moreover, make the mistake of thinking that logical explanation is sufficient: "If only people would read the instructions," they say, "everything would be all right."<p>> Engineers are trained to think logically. As a result, they come to believe that all people must think this way, and they design their machines accordingly. When people have trouble, the engineers are upset, but often for the wrong reason. "What are these people doing" they will wonder. "Why are they doing that?" The problem with the designs of most engineers is that they are too logical. We have to accept human behavior the way it is, not the way we would wish it to be.<p>— Don Norman, <i>The Design of Everyday Things</i>
Having worked in a group with new developers, a big challenge was git ... a big flowchart image of the next action to perform was passed around. Will check this out.