Live data from Hacker News

The lazy Git UI you didn't know you need

bwplotka.dev

101–110 of 224 posts

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

#101
post #65

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…

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

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

#102
post #8
post #5

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/ju…

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…

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.

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

#103
post #5

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/ju…

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.

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

#104
post #99
post #96

Earlier quoted context omitted.

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.

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

#105
post #8

Earlier quoted context omitted.

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…

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.

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

#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 sure svn got decent merging.

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

#108
post #28
post #7

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…

I find both Fork and Tower to be much better than SourceTree, have you only tried free tools?

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.

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

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

But then you have to use VSCode, and that's never a good thing.
Post reply on HN