[HN Gopher] Lazygit Turns 5: Musings on Git, TUIs, and open source
___________________________________________________________________
Lazygit Turns 5: Musings on Git, TUIs, and open source
Author : jesseduffield
Score : 181 points
Date : 2023-08-05 07:39 UTC (15 hours ago)
(HTM) web link (jesseduffield.com)
(TXT) w3m dump (jesseduffield.com)
| roland35 wrote:
| 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!
| arcanemachiner wrote:
| I just discovered this project a couple weeks ago. Total game
| changer.
| iscream26 wrote:
| > 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_
| camgunz wrote:
| 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_.
| theusus wrote:
| Also warp requires you to sign in before you use it. That's
| stupid imo
| williamdclt wrote:
| 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 wrote:
| I'm pretty sure there isn't a vi lib, would be cool, but I
| think it's just a reimplementation.
| chungy wrote:
| 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.
| shrubble wrote:
| 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.
| keyle wrote:
| 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 :)
| nathell wrote:
| > 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 wrote:
| > > 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 wrote:
| Nah, it won because of GitHub.
| chungy wrote:
| It won well before GitHub. and I always liked it better
| than Mercurial too :)
| meepmorp wrote:
| Basically. I liked mercurial better than git, but GitHub's
| become the center of gravity for a lot of development.
| jesseduffield wrote:
| Whoops! I should have fact-checked that: I had it in my head
| that it was recent based on there being so much recent
| discussion of it online. I've updated the post
| toastal wrote:
| 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.
| rgoulter wrote:
| 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.
| lionkor wrote:
| 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.
| Blackthorn wrote:
| Counterpoint: there's nothing wrong with pull with merge.
| lionkor wrote:
| Whats to like about Merged master into
| master
|
| commits
| yCombLinks wrote:
| That should be telling you that git is designed
| unintuitively, not that everyone else is wrong.
| formerly_proven wrote:
| It tells us that git supports multiple workflows and some
| of the defaults are for a workflow that most git users
| don't use.
| Hendrikto wrote:
| 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 wrote:
| 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.
| rectang wrote:
| 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.
| goku12 wrote:
| > 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 wrote:
| 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 wrote:
| > 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.t...
|
| [2]: https://book.mercurial-scm.org/read/undo.html#rolling-
| back-a...
| Espressosaurus wrote:
| 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
| goku12 wrote:
| Git has a reputation for having one of the most confusing
| CLIs ever. However, it's probably better to decide what
| operations you want to do and work from there to find out
| the commands needed. That obviates the need to learn so
| many commands and switches - for me, at least. My
| training material was also designed like that. My
| students use them like cheat-sheets until they get
| familiar enough.
| magicalhippo wrote:
| The thing is, I want to design and write code. I don't
| want to remember a bunch of command line parameters for
| other stuff.
|
| With Mercurial I didn't have to, it just flowed.
| Tempest1981 wrote:
| 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.
| goku12 wrote:
| > I'm the minority suggesting the cli as a good way to use
| git.
|
| I'm someone who used to train newbie staff using the git
| CLI. As the other commenter pointed out, the CLI often
| doesn't feel very intuitive. However, I personally felt
| that it's hard to convey what's happening behind the scenes
| unless you're on the CLI. And in git, it's very important
| to know the underlying data format and operations - unlike
| in case of Mercurial, for example.
| gettodachoppa wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| goku12 wrote:
| The tree state is saved as snapshots. However, operations
| like merging (3-way merge) and rebase are certainly based
| on diffs/patches.
|
| For example, consider the case of an interactive rebase
| where you delete a commit. If it was based on snapshots,
| only that commit should disappear. The changes introduced
| by that commit should remain in the subsequent
| snapshots/commits. However, that is not what happens. The
| change introduced by the commit disappears from all
| subsequent commits/snapshots. This means that all the
| subsequent snapshots are modified by subtracting the
| patch from the commit that was deleted.
| jimbobimbo wrote:
| 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.
| keb_ wrote:
| Lazygit and Lazydocker are great. Now can you please make a
| Lazynginx? :)
| jackbravo wrote:
| 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.
| JimRyan wrote:
| What features would you want in lazynginx, out of curiosity?
| thomasfromcdnjs wrote:
| 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.
| dang wrote:
| Related:
|
| _Lazygit: Simple terminal UI for Git commands_ -
| 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 - Nov 2021 (141
| comments)
|
| _Show HN: I made a tool that made me faster at Git_ -
| https://news.ycombinator.com/item?id=17689014 - Aug 2018 (229
| comments)
| sundarurfriend wrote:
| 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.
| FeepingCreature wrote:
| > 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 wrote:
| 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.
| Niksko wrote:
| Congrats on 5 years Jesse! Always warms my heart when I see one
| of your projects pop up on HN.
| TillE wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-05 23:01 UTC)