13 ms·

Lazygit Turns 5: Musings on Git, TUIs, and open source

211 points by jesseduffield 3y ago

Niksko 3y ago
Congrats on 5 years Jesse! Always warms my heart when I see one of your projects pop up on HN.
- jesseduffield 3y ago
  Thanks!
rgoulter 3y ago
I would have thought most discussions around "UI vs CLI" are more about "GUI vs CLI". Keyboard-driven git UI's which aren't GUI are relatively niche. (I can think of magit, tig, and lazygit). 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.
- goku12 3y ago
  > 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. How true is this? I believed that people learned git using the CLI. I learned git from the official book - pro-git. It's entirely based on the CLI. I've trained many to use git - again with CLI. Magit is fun to use - primarily because its UI is directly based on the CLI paradigms. Magit is often just a shortcut for the git CLI (using transient menus). I was never really able to settle on a GUI, other than for inspecting the commit graph/DAG. The only VC tool I learned with a GUI was subversion, using TortoiseSVN. But the limitations of that GUI was very apparent and had to drop it soon afterwards.
  - jemmyw 3y ago
    I learned and mainly use the cli but I would say it's true that most devs I've spoken to do not. Whenever the topic comes up I feel like I'm the minority suggesting the cli as a good way to use git. The problem is if you mainly use a UI and get into a bad state then the UI tends to make it worse and you have a bad mental model so you're left asking for help and finding it hard to describe what you need. That's my experience anyway, I see that happen about once a month among my peers.
    - magicalhippo 3y ago
      > I feel like I'm the minority suggesting the cli as a good way to use git. I used Mercurial a lot before trying Git for the first time, the projects then switched to Git. With Mercurial I felt right at home with the command line. Everything was simple and made sense, and I seldom had to consult the documentation after a short time learning it. I never felt the need for a GUI, or that it would improve things. With Git it was the complete opposite. Nothing made sense at the command line. I had to do web searches for just about everything I did, either to figure out what arcane set of switches to use or to make sure I didn't fuck things up. After a short while I gave up and found a GUI, which made Git much, much better to use. Perhaps things have improved somewhat, I hear they've cleaned up the command line options a bit. But looking at the manual[1] its clearly still far from Mercurial-level of usability[2]. [1]: https://git-scm.com/docs/git-reset#Documentation/git-reset.txt-Undoacommitandredo https://git-scm.com/docs/git-reset#Documentation/git-reset.t... [2]: https://book.mercurial-scm.org/read/undo.html#rolling-back-a-transaction https://book.mercurial-scm.org/read/undo.html#rolling-back-a...
      - Espressosaurus 3y ago
        Things aren't any better. I've given up on the Git command line. I'm never going to remember the various flags-vs-unintuitively-named commands. TortoiseGit is ugly and sucks, but the only time I've had to drop to the command line is when I need to look for the intersection or disjoint commits
        Tempest1981 3y ago
        Let's not trash TortoiseGit. Sven has put so much work and polish into it. Ugly? Maybe you just hate Win32 UIs? That's ok. TortoiseGit has many great features, including ways to compare anything you can think of.
        Espressosaurus 3y ago
        So far it's been the best free Git client I've used, but I miss TortoiseHg's interface. I'm still not over Mercurial losing the DVCS wars.
  - gettodachoppa 3y ago
    Good morning I hate git All of my co-workers use git GUIs. I use the CLI, not out of love for it, but because git is so needlessly complex and arcane that I'm scared to use GUIs. For every other tool, I prefer to use GUIs, but they're simple enough that I don't get surprised and there's no major consequences (such as making me spend 2 hours researching a solution) if there's an issue. Not so with git. Git has an awful CLI. It's needlessly complex for 99.999% of projects. I write in Evernote notebooks as a learning journal and also a personal knowledge base (howto guides, troubleshooting guide, snippets, etc). Every note is written for a good reason, there's no meaningless info in it. Here is the number of notes in my git notebook, along with a few others for comparison: -git: 55 notes -Linux: 200 notes -C++: 130 notes It's insane that git occupies so much mental space considering it's a single-purpose tool. I truly wish it was never created, or at least never caught on, we might have another decentralized VCS dominating the space with an interface written for normal people. If anyone other than Linus Torvalds had written it, we would all be using something else. If midwit geeks weren't so vain and wanted to feel cool for using the same VCS as the Linux kernel, we could've been using something else. (No, I can't choose to use something else, the dominant winner affects you whether you like it or not, same as IE6 and Chrome.)
    - goku12 3y ago
      > It's insane that git occupies so much mental space considering it's a single-purpose tool. No arguments here. What I meant is that it's very hard for me to understand what's happening behind the scenes unless I'm using the CLI. The tool is hard nevertheless. > If midwit geeks weren't so vain and wanted to feel cool for using the same VCS as the Linux kernel, we could've been using something else. The fact is, git won. I was personally into mercurial. The CLI was much more sane. One of the biggest issue with git is that it uses both the snapshot model (for the storage format) and the diff/patch model (for many operations like merge and rebase). You have to know which of these applies to any operation for it to make sense.
      - Hendrikto 3y ago
        > One of the biggest issue with git is that it uses both the snapshot model and the diff/patch model Git always uses snapshots. The diff thing is just a question of how this is exposed in the UI.
- lionkor 3y ago
  The issue with those git guis like the vscode one or github desktop is that they fundamentally misunderstand git. they make it the default to merge current branch into current branch (pull with merge) and they default to committing large amounts of code under a simple message. i know fulltime devs who use git every day, who have no idea what a rebase is - they think merge does what really rebase does, and thats mostly the fault of bad defaults. git commit -p should be the default committing interface also; assuming you like git history which can be bisected, reverted, etc.
  - yCombLinks 3y ago
    That should be telling you that git is designed unintuitively, not that everyone else is wrong.
    - rectang 3y ago
      We can have high expectations for those who aspire to improve on Git — that they will grok its strengths, weaknesses, and underlying model thoroughly. Even if they cater to novice users, they aren’t novice users themselves and lack of experience is no longer an excuse when Git wrapper authors make bad choices about defaults.
    - Hendrikto 3y ago
      If that was the case, things would be different with other VCSs. In my experience, that isn’t true. The main problem is that many people just don’t care, and view VCS as an afterthought, after the actual work is done. They don’t even know how powerful git can be when used optimally. Maintaining a clean git history is work. You have to think about it, and invest into it. But it is well worth it, in the mid to long term.
      - __jonas 3y ago
        Yes exactly, I don’t care. I want to write code and not constantly spend time thinking about the structure and semantics of my version control system. I understand different projects have different requirements for version control, but as someone who does not work on massive codebases with a huge amount of collaborators I enjoy that the GUI I use somewhat hides the complexity I don’t want to engage with.
- jimbobimbo 3y ago
  I have 20+ year of professional experience and the only command I know by heart is how to force add an ignored file. Visual Studio has an excellent history browser when I need to operate on specific commits. Both Visual Studio and Visual Studio Code have great basic git capabilities and amazing conflict editors to never touch the cli.
keyle 3y ago
I use lazygit every day, so much I just type lz. It's an awesome project, highly recommend. 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 :)
arcanemachiner 3y ago
I just discovered this project a couple weeks ago. Total game changer.
sundarurfriend 3y ago
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. 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.
shrubble 3y ago
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.
FeepingCreature 3y ago
> When I create a commit, several things happen: > my staged files disappear from my list of file changes > a new commit is appended to my git log > my branch ends up with a new head commit, diverging from its upstream > If you create a commit from the command line, you see none of this. Sure, if you're not using an addon like powerline-shell. If you do, all of those are immediately obvious. I'd argue it's less "commandline bad" and more "stock commandline bad."
- euroderf 3y ago
  This is my problem with git. SO many moving parts to visualize. So on the topic of visualization, can someone make a simple(?) GUI tool that has all these entities, and sequentially animates some arrows, with annotations, showing just what the heck is going on ? Do it for the most commonly used commands but also for the rarely-used ones. And for every command that invokes it (presumably using a hook), then display OK/Cancel. Git training wheels. Meant to be abandoned once you get the hang of it.
- zeroimpl 3y ago
  Precisely this. Most of my coworkers seem to use a prompt that just reports what branch you are on. I use a power line-based prompt that captures a lot more info, and so I virtually never end up in a situation where I forgot to include files or forgot to push my commit since it’s super obvious.
toastal 3y ago
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.
- lioeters 3y ago
  I agree, and I almost closed the program when it started for the first time, showing me a pop-up telling me how I "rock" for using it, asking me to star or donate, a YouTube link for a tutorial, etc. I prefer my programs to be silent and invisible, and I have a low tolerance for programs that advertise themselves. But once closed, I was not bothered again. The program itself feels great, like it could become a daily tool.
nathell 3y ago
> Fossil is a recent git alternative It’s almost as old as git. Fossil has been around since 2006, while git was born in 2005. > Merge conflicts aren’t first class 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.
- chungy 3y ago
  > > Fossil is a recent git alternative > It’s almost as old as git. Fossil has been around since 2006, while git was born in 2005. I'm assuming the author recently discovered fossil, but it is an absurd statement regardless :) I've sort of wanted to use fossil for a real project of my own, but its own idea of workflows just... puts me off completely. I stick to Git. Git won the minds of developers not because it was first (by far, it wasn't), but because it's better than the rest.
  - thfuran 3y ago
    Nah, it won because of GitHub.
    - meepmorp 3y ago
      Basically. I liked mercurial better than git, but GitHub's become the center of gravity for a lot of development.
    - chungy 3y ago
      It won well before GitHub. and I always liked it better than Mercurial too :)
      - thfuran 3y ago
        That's just not true. SVN was more popular than git until several years after GitHub was founded. Mercurial was reasonably popular as well.
        3y ago
roland35 3y ago
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!
camgunz 3y ago
I think I may have said this before but: > Warp: a terminal emulator whose killer feature is allowing you to edit your command as if you were in vscode/sublime 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 glorious.
- chungy 3y ago
  You can also do C-x C-e in bash and it'll open your current prompt input in $EDITOR. You can even start doing multi-line input the easy way through this method.
- theusus 3y ago
  Also warp requires you to sign in before you use it. That's stupid imo
  - HumanOstrich 3y ago
    Agreed. I immediately nuked Warp when it demanded that I sign in to use it.
- williamdclt 3y ago
  I did not know readline supported it!! This is great info Aside: how is it implemented? Does readline have to reimplement vi style editing; or is there some sort of vi lib?
  - camgunz 3y ago
    I'm pretty sure there isn't a vi lib, would be cool, but I think it's just a reimplementation.
- mdwalters 3y ago
  no fish support? :(
  - 3y ago
iscream26 3y ago
> 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." > 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. — Don Norman, The Design of Everyday Things
dang 3y ago
Related: Lazygit: Simple terminal UI for Git commands - https://news.ycombinator.com/item?id=36782018 https://news.ycombinator.com/item?id=36782018 - July 2023 (79 comments) Lazygit: A simple terminal UI for Git commands - https://news.ycombinator.com/item?id=29394162 https://news.ycombinator.com/item?id=29394162 - Nov 2021 (141 comments) Show HN: I made a tool that made me faster at Git - https://news.ycombinator.com/item?id=17689014 https://news.ycombinator.com/item?id=17689014 - Aug 2018 (229 comments)
toastercat 3y ago
Lazygit and Lazydocker are great. Now can you please make a Lazynginx? :)
- JimRyan 3y ago
  What features would you want in lazynginx, out of curiosity?
  - thomasfromcdnjs 3y ago
    I personally would love a simple way to do a reverse proxy. It is not hard, but could be as easy as writing the hostname you want and what it points at.
  - toastercat 3y ago
    Just a simpler interface for creating reverse proxies or static sites and also maybe do automatic SSL as a cherry on top. Basically, I want something like Nginx Proxy Manager, but more lightweight and terminal friendly.
- jackbravo 3y ago
  maybe try using caddyserver.com instead of nginx? It is also a go project, and has a very simple configuration syntax. The automatic SSLs feature is what made my try it in the first place.
  - mdeeks 3y ago
    Caddy is great! But has the absolutely insane default of logging all headers. Make sure you change that before you log auth headers
    - mholt 3y ago
      We don't log all headers. By default, we don't log headers that are likely to contain credentials (Cookie, Set-Cookie, Authorization, Proxy-Authorization): https://github.com/caddyserver/caddy/blob/a8cc5d1a7d9d80e12ab895beaf4eaed34cc6bded/modules/caddyhttp/marshalers.go#L68-L81 https://github.com/caddyserver/caddy/blob/a8cc5d1a7d9d80e12a...
TillE 3y ago
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. 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.
sublinear 3y ago
> 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. Doesn't the conclusion seem obvious? Most devs aren't Apple fans.
sublinear 3y ago
> 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. 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.

211 points by jesseduffield 3y ago

Niksko 3y ago

Congrats on 5 years Jesse! Always warms my heart when I see one of your projects pop up on HN.

jesseduffield 3y ago
Thanks!

rgoulter 3y ago

I would have thought most discussions around "UI vs CLI" are more about "GUI vs CLI". Keyboard-driven git UI's which aren't GUI are relatively niche. (I can think of magit, tig, and lazygit). 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.

goku12 3y ago
> 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. How true is this? I believed that people learned git using the CLI. I learned git from the official book - pro-git. It's entirely based on the CLI. I've trained many to use git - again with CLI. Magit is fun to use - primarily because its UI is directly based on the CLI paradigms. Magit is often just a shortcut for the git CLI (using transient menus). I was never really able to settle on a GUI, other than for inspecting the commit graph/DAG. The only VC tool I learned with a GUI was subversion, using TortoiseSVN. But the limitations of that GUI was very apparent and had to drop it soon afterwards.
- jemmyw 3y ago
  I learned and mainly use the cli but I would say it's true that most devs I've spoken to do not. Whenever the topic comes up I feel like I'm the minority suggesting the cli as a good way to use git. The problem is if you mainly use a UI and get into a bad state then the UI tends to make it worse and you have a bad mental model so you're left asking for help and finding it hard to describe what you need. That's my experience anyway, I see that happen about once a month among my peers.
  - magicalhippo 3y ago
    > I feel like I'm the minority suggesting the cli as a good way to use git. I used Mercurial a lot before trying Git for the first time, the projects then switched to Git. With Mercurial I felt right at home with the command line. Everything was simple and made sense, and I seldom had to consult the documentation after a short time learning it. I never felt the need for a GUI, or that it would improve things. With Git it was the complete opposite. Nothing made sense at the command line. I had to do web searches for just about everything I did, either to figure out what arcane set of switches to use or to make sure I didn't fuck things up. After a short while I gave up and found a GUI, which made Git much, much better to use. Perhaps things have improved somewhat, I hear they've cleaned up the command line options a bit. But looking at the manual[1] its clearly still far from Mercurial-level of usability[2]. [1]: https://git-scm.com/docs/git-reset#Documentation/git-reset.txt-Undoacommitandredo https://git-scm.com/docs/git-reset#Documentation/git-reset.t... [2]: https://book.mercurial-scm.org/read/undo.html#rolling-back-a-transaction https://book.mercurial-scm.org/read/undo.html#rolling-back-a...
    - Espressosaurus 3y ago
      Things aren't any better. I've given up on the Git command line. I'm never going to remember the various flags-vs-unintuitively-named commands. TortoiseGit is ugly and sucks, but the only time I've had to drop to the command line is when I need to look for the intersection or disjoint commits
      - Tempest1981 3y ago
        Let's not trash TortoiseGit. Sven has put so much work and polish into it. Ugly? Maybe you just hate Win32 UIs? That's ok. TortoiseGit has many great features, including ways to compare anything you can think of.
        Espressosaurus 3y ago
        So far it's been the best free Git client I've used, but I miss TortoiseHg's interface. I'm still not over Mercurial losing the DVCS wars.
- gettodachoppa 3y ago
  Good morning I hate git All of my co-workers use git GUIs. I use the CLI, not out of love for it, but because git is so needlessly complex and arcane that I'm scared to use GUIs. For every other tool, I prefer to use GUIs, but they're simple enough that I don't get surprised and there's no major consequences (such as making me spend 2 hours researching a solution) if there's an issue. Not so with git. Git has an awful CLI. It's needlessly complex for 99.999% of projects. I write in Evernote notebooks as a learning journal and also a personal knowledge base (howto guides, troubleshooting guide, snippets, etc). Every note is written for a good reason, there's no meaningless info in it. Here is the number of notes in my git notebook, along with a few others for comparison: -git: 55 notes -Linux: 200 notes -C++: 130 notes It's insane that git occupies so much mental space considering it's a single-purpose tool. I truly wish it was never created, or at least never caught on, we might have another decentralized VCS dominating the space with an interface written for normal people. If anyone other than Linus Torvalds had written it, we would all be using something else. If midwit geeks weren't so vain and wanted to feel cool for using the same VCS as the Linux kernel, we could've been using something else. (No, I can't choose to use something else, the dominant winner affects you whether you like it or not, same as IE6 and Chrome.)
  - goku12 3y ago
    > It's insane that git occupies so much mental space considering it's a single-purpose tool. No arguments here. What I meant is that it's very hard for me to understand what's happening behind the scenes unless I'm using the CLI. The tool is hard nevertheless. > If midwit geeks weren't so vain and wanted to feel cool for using the same VCS as the Linux kernel, we could've been using something else. The fact is, git won. I was personally into mercurial. The CLI was much more sane. One of the biggest issue with git is that it uses both the snapshot model (for the storage format) and the diff/patch model (for many operations like merge and rebase). You have to know which of these applies to any operation for it to make sense.
    - Hendrikto 3y ago
      > One of the biggest issue with git is that it uses both the snapshot model and the diff/patch model Git always uses snapshots. The diff thing is just a question of how this is exposed in the UI.
lionkor 3y ago
The issue with those git guis like the vscode one or github desktop is that they fundamentally misunderstand git. they make it the default to merge current branch into current branch (pull with merge) and they default to committing large amounts of code under a simple message. i know fulltime devs who use git every day, who have no idea what a rebase is - they think merge does what really rebase does, and thats mostly the fault of bad defaults. git commit -p should be the default committing interface also; assuming you like git history which can be bisected, reverted, etc.
- yCombLinks 3y ago
  That should be telling you that git is designed unintuitively, not that everyone else is wrong.
  - rectang 3y ago
    We can have high expectations for those who aspire to improve on Git — that they will grok its strengths, weaknesses, and underlying model thoroughly. Even if they cater to novice users, they aren’t novice users themselves and lack of experience is no longer an excuse when Git wrapper authors make bad choices about defaults.
  - Hendrikto 3y ago
    If that was the case, things would be different with other VCSs. In my experience, that isn’t true. The main problem is that many people just don’t care, and view VCS as an afterthought, after the actual work is done. They don’t even know how powerful git can be when used optimally. Maintaining a clean git history is work. You have to think about it, and invest into it. But it is well worth it, in the mid to long term.
    - __jonas 3y ago
      Yes exactly, I don’t care. I want to write code and not constantly spend time thinking about the structure and semantics of my version control system. I understand different projects have different requirements for version control, but as someone who does not work on massive codebases with a huge amount of collaborators I enjoy that the GUI I use somewhat hides the complexity I don’t want to engage with.
jimbobimbo 3y ago
I have 20+ year of professional experience and the only command I know by heart is how to force add an ignored file. Visual Studio has an excellent history browser when I need to operate on specific commits. Both Visual Studio and Visual Studio Code have great basic git capabilities and amazing conflict editors to never touch the cli.

keyle 3y ago

I use lazygit every day, so much I just type lz. It's an awesome project, highly recommend. 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 :)

arcanemachiner 3y ago

I just discovered this project a couple weeks ago. Total game changer.

sundarurfriend 3y ago

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. 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.

shrubble 3y ago

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.

FeepingCreature 3y ago

> When I create a commit, several things happen: > my staged files disappear from my list of file changes > a new commit is appended to my git log > my branch ends up with a new head commit, diverging from its upstream > If you create a commit from the command line, you see none of this. Sure, if you're not using an addon like powerline-shell. If you do, all of those are immediately obvious. I'd argue it's less "commandline bad" and more "stock commandline bad."

euroderf 3y ago
This is my problem with git. SO many moving parts to visualize. So on the topic of visualization, can someone make a simple(?) GUI tool that has all these entities, and sequentially animates some arrows, with annotations, showing just what the heck is going on ? Do it for the most commonly used commands but also for the rarely-used ones. And for every command that invokes it (presumably using a hook), then display OK/Cancel. Git training wheels. Meant to be abandoned once you get the hang of it.
zeroimpl 3y ago
Precisely this. Most of my coworkers seem to use a prompt that just reports what branch you are on. I use a power line-based prompt that captures a lot more info, and so I virtually never end up in a situation where I forgot to include files or forgot to push my commit since it’s super obvious.

toastal 3y ago

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.

lioeters 3y ago
I agree, and I almost closed the program when it started for the first time, showing me a pop-up telling me how I "rock" for using it, asking me to star or donate, a YouTube link for a tutorial, etc. I prefer my programs to be silent and invisible, and I have a low tolerance for programs that advertise themselves. But once closed, I was not bothered again. The program itself feels great, like it could become a daily tool.

nathell 3y ago

> Fossil is a recent git alternative It’s almost as old as git. Fossil has been around since 2006, while git was born in 2005. > Merge conflicts aren’t first class 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.

chungy 3y ago
> > Fossil is a recent git alternative > It’s almost as old as git. Fossil has been around since 2006, while git was born in 2005. I'm assuming the author recently discovered fossil, but it is an absurd statement regardless :) I've sort of wanted to use fossil for a real project of my own, but its own idea of workflows just... puts me off completely. I stick to Git. Git won the minds of developers not because it was first (by far, it wasn't), but because it's better than the rest.
- thfuran 3y ago
  Nah, it won because of GitHub.
  - meepmorp 3y ago
    Basically. I liked mercurial better than git, but GitHub's become the center of gravity for a lot of development.
  - chungy 3y ago
    It won well before GitHub. and I always liked it better than Mercurial too :)
    - thfuran 3y ago
      That's just not true. SVN was more popular than git until several years after GitHub was founded. Mercurial was reasonably popular as well.
      - 3y ago

roland35 3y ago

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!

camgunz 3y ago

I think I may have said this before but: > Warp: a terminal emulator whose killer feature is allowing you to edit your command as if you were in vscode/sublime 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 glorious.

chungy 3y ago
You can also do C-x C-e in bash and it'll open your current prompt input in $EDITOR. You can even start doing multi-line input the easy way through this method.
theusus 3y ago
Also warp requires you to sign in before you use it. That's stupid imo
- HumanOstrich 3y ago
  Agreed. I immediately nuked Warp when it demanded that I sign in to use it.
williamdclt 3y ago
I did not know readline supported it!! This is great info Aside: how is it implemented? Does readline have to reimplement vi style editing; or is there some sort of vi lib?
- camgunz 3y ago
  I'm pretty sure there isn't a vi lib, would be cool, but I think it's just a reimplementation.
mdwalters 3y ago
no fish support? :(
- 3y ago

iscream26 3y ago

> 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." > 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. — Don Norman, The Design of Everyday Things

dang 3y ago

Related: Lazygit: Simple terminal UI for Git commands - https://news.ycombinator.com/item?id=36782018 https://news.ycombinator.com/item?id=36782018 - July 2023 (79 comments) Lazygit: A simple terminal UI for Git commands - https://news.ycombinator.com/item?id=29394162 https://news.ycombinator.com/item?id=29394162 - Nov 2021 (141 comments) Show HN: I made a tool that made me faster at Git - https://news.ycombinator.com/item?id=17689014 https://news.ycombinator.com/item?id=17689014 - Aug 2018 (229 comments)

toastercat 3y ago

Lazygit and Lazydocker are great. Now can you please make a Lazynginx? :)

JimRyan 3y ago
What features would you want in lazynginx, out of curiosity?
- thomasfromcdnjs 3y ago
  I personally would love a simple way to do a reverse proxy. It is not hard, but could be as easy as writing the hostname you want and what it points at.
- toastercat 3y ago
  Just a simpler interface for creating reverse proxies or static sites and also maybe do automatic SSL as a cherry on top. Basically, I want something like Nginx Proxy Manager, but more lightweight and terminal friendly.
jackbravo 3y ago
maybe try using caddyserver.com instead of nginx? It is also a go project, and has a very simple configuration syntax. The automatic SSLs feature is what made my try it in the first place.
- mdeeks 3y ago
  Caddy is great! But has the absolutely insane default of logging all headers. Make sure you change that before you log auth headers
  - mholt 3y ago
    We don't log all headers. By default, we don't log headers that are likely to contain credentials (Cookie, Set-Cookie, Authorization, Proxy-Authorization): https://github.com/caddyserver/caddy/blob/a8cc5d1a7d9d80e12ab895beaf4eaed34cc6bded/modules/caddyhttp/marshalers.go#L68-L81 https://github.com/caddyserver/caddy/blob/a8cc5d1a7d9d80e12a...

TillE 3y ago

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. 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.

sublinear 3y ago

> 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. Doesn't the conclusion seem obvious? Most devs aren't Apple fans.

sublinear 3y ago

> 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. 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.