Live data from Hacker News

The lazy Git UI you didn't know you need

bwplotka.dev

131–140 of 224 posts

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

#131

Earlier quoted context omitted.

I have tried jj several times but I feel like it slows me down significantly because I can’t grok the workflow. I like to do a bunch of changes then quickly select them in my editor and commit them, breaking them up into different commits to keep them organized. With jj’s lack of editor integration, I don’t know how to do this with the cli alone so I end up with bigger messier commits.

You want "jj commit -i". You'll get an interface that lets you choose files, chunks, or lines to commit.

Sold!

I'm trying jj. I've seen enough mentions now. I've never read anything about it.

I hope it's compatible with git.

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

#132
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…

On Windows I've been using TortoiseGit for over a decade now and in terms of Git power user features in a GUI I think it's unmatched.

People who defend the CLI as the only real way to use Git simply haven't used a decent GUI for it. I consider myself a very advanced Git user, but I barely know the CLI commands off the top of my head.

A GUI really makes a lot of sense for something like Git, most of the time what you want to do is "contextual' from something like a list of files to commit or a log of commits and TortoiseGit is pretty good about exposing whatever you'd need to do.

I find that with GitKraken (aside from not being free), I just don't feel in control of what I'm trying to achieve with Git.

Git Extensions seemed pretty decent and possibly a nicer GUI paradigm than TortoiseGit, but when I tried it I found TortoiseGit to offer more power to me.

One thing that does annoy me a bit about TortoiseGit is that it has this philosophy of a new Window for everything, which for most things is not a problem, but is in a couple of places. For example, to work on a repository you tend to have to use the Explorer context menu to do things. I tend to open the git log window once and leave it open, and from it I can do pretty much everything. If it had some sort of "main app" view with a tab per repository you have open that would be awesome, instead of my having to have multiple open log windows. Similarly, for commits and PRs I like to double check each file's diffs. Its UI opens each one in a new window, but if it would rather have a sub pane from the commit view I think it would work better.

I used to use SourceTree in conjunction with TortoiseGit because I liked its tabbed UI for the simple things like pulling/fetching/pushing, switching branches, but I stopped using it about 5 years ago, the Windows version of it felt neglected in that it would often crash or become very slow.

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

#135
post #68

Earlier quoted context omitted.

You can do "see only current branch" with the little filter icon when you hover next to a branch. Although I do find myself getting lost amongst branches more easily compared to Sourcetree, I think there's some difference in how filters are combined that isn't ideal (but I can't remember specifics)

You can also go to View in the menu and click "Filter by active branch" (Ctrl+Shift+A). Also if you, like me, wanted to blame or view history for specific files there does not seem to be a way by clicking in the GUI to achieve it. But by using Ctrl+P you get the command search and can search for "Blame" or "File history".

I use file history aaaall the time. My favourite feature in Fork.

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

#136

Anyone used GitKraken? I haven’t, but for reasons, I’m interested to hear about your experience with it.

Gitkraken is the best, and I can't believe anyone would voluntarily use Sourcetree over it.

I've used gitkraken for over 9 years and it's great for both newbies and pros.

It completely solves the problem with new or intermediate devs, who are not used to working in a sizable team, constantly needing hand-holding.

Lots of people resist adopting it at first, but not one has regretted it so far. It usually goes like this:

1. "No I won't use it, the terminal is better"

2. Mess up

3. Finally give gitkraken a serious try

4. Realize they didn't really know git

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

#137

Earlier quoted context omitted.

You want "jj commit -i". You'll get an interface that lets you choose files, chunks, or lines to commit.

Sold! I'm trying jj. I've seen enough mentions now. I've never read anything about it. I hope it's compatible with git.

The compatibility with git is the whole reason it's so popular (just run `jj git init --colocate` in your git repo). You can use it without forcing your collaborators to switch from git and you can use it will a git forges as well.

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

#138
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…

also just to add that I've noticed that `jj` comes way easier and more intuitive to newbies I've mentored. Just yesterday I told a friend to commit his changes and he just wanted to do `git commit` (without remembering to do `git add` first). This made me realize we should just install `jujutsu` for him and he's been committing very diligently afterwards. Can recommend trying this with any people you mentor/teach.

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

#139

Earlier quoted context omitted.

As much as I heartily disagree with most of what you wrote - and seeing all the downvotes, I'm not the only one - there is a nugget of truth in what you wrote, which answers a lot of your complaints. "Using it was a harsh reminder of what people running emacs or vim for the first time have to go through." The benefit of keyboard-driven programs like Vim is that you're trading an initial learning curve for a vastly mo…

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

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

#140
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…

Did you try magit? There's a bit of learning curve as it's built on top of Emacs, but it's entirely keyboard driven. I still have to find a workflow that it does not support.

There's gitu[0] if you want a similar experience without Emacs.

[0] https://github.com/altsem/gitu

Post reply on HN