The lazy Git UI you didn't know you need • Hacker News Board

Re: The lazy Git UI you didn't know you need

#211

Post by witcher » Wed, Nov 12, 2025, 9:43 AM UTC

EMM_386 wrote: post #97

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.

(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

Re: The lazy Git UI you didn't know you need

#212

Post by witcher » Wed, Nov 12, 2025, 9:50 AM UTC

gwbas1c wrote: post #183

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 fo…

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

Re: The lazy Git UI you didn't know you need

#213

Post by witcher » Wed, Nov 12, 2025, 9:53 AM UTC

gpderetta wrote: post #155

keyle wrote: post #63

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…

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

Re: The lazy Git UI you didn't know you need

#214

Post by witcher » Wed, Nov 12, 2025, 9:55 AM UTC

kazinator wrote: post #49

"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…

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

Re: The lazy Git UI you didn't know you need

#215

Post by gpderetta » Wed, Nov 12, 2025, 10:29 AM UTC

witcher wrote: post #213

gpderetta wrote: post #155

Earlier quoted context omitted.

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

Re: The lazy Git UI you didn't know you need

#216

Post by sevenseacat » Wed, Nov 12, 2025, 12:13 PM UTC

unixplumber wrote: post #184

varunramesh wrote: post #2

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.

Re: The lazy Git UI you didn't know you need

#217

Post by scotty79 » Wed, Nov 12, 2025, 4:35 PM UTC

alwillis wrote: post #188

scotty79 wrote: post #107

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…

> 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 Mercurial: hg add Committing Changes: SVN: svn commit -m "Commit message" (commits changes directly to the central repository) Mercurial: hg commit -m "Commit message" (com…

And partial checkout?

Re: The lazy Git UI you didn't know you need

#218

Post by WolfeReader » Wed, Nov 12, 2025, 4:54 PM UTC

mbork_pl wrote: post #139

nice_byte wrote: post #39

Earlier quoted context omitted.

> 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 e…

> 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

Re: The lazy Git UI you didn't know you need

#219

Post by jimbokun » Wed, Nov 12, 2025, 6:18 PM UTC

wredcoll wrote: post #103

moron4hire wrote: post #92

Earlier quoted context omitted.

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…

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.

Re: The lazy Git UI you didn't know you need

#220

Post by Jianghong94 » Thu, Nov 13, 2025, 12:39 AM UTC

witcher wrote: post #209

Jianghong94 wrote: post #176

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 fi…

(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. ID…

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.