Hacker News Reader

Comment by thealistra | Hacker News Reader

I don't like GUI git tools as they always have issues with edge cases. git is a complicated system and you can have multiple weird configurations in your repo/system.

Most of the GUI tools just focus on the MVP workflow and often they crash/bug out on the weird cases.

This is not really an argument against it, but just an observation I made through the years.

Sourcetree is one of the oldest GUI git clients and it has the most stuff handled correctly, and this basically looks like open-source source tree.

View on HN

In my opinion git GUIs have two major adventages:

1. you can see all the information at on glance: current branch, all local branches all remotes and remot branches, local changes, recent commits, current merge conflics

2. cherry picking single lines for staging in multiple files is much faster in a GUI than via terminal (maybe there are clever tricks to make it easier I don't know of)

`git add -p` is pretty fast for staging parts of files

Unless I'm missing something - it only shows you a hunk, without much (or any) context. It's relatively fast to stage hunk like this, but you are doing it like blindly.

An alternative is using TUI application like vim in conjunction with tools like recountdiff and git apply to handle staging and unstaging parts of files.

You get more context because you can see other parts of the diff in the editor, unlike when using the -p switch with the git add or reset commands.

I'm actually using NeoVIM + fugitive and git-gutter.

GitGutter make working with hunks easy

Looking at the README of vim-gitgutter[1] (assuming that's the plugin you're referring to), it says the following:

>> You cannot unstage a staged hunk.

I'm not sure if that's a feature they plan to support, but something like this could easily be done by highlighting the hunk displayed when running git diff --cached in vim's linewise visual mode and filtering it through git apply -R --cached -.

[1] https://github.com/airblade/vim-gitgutter

I use git add -p almost exclusively & I'm a big fan, to me the limitation is when the part I want to stage and the part I don't are so close together that they get presented to me as a single atomic chunk to add/not add.

Do you ever hit 'e' to edit? You can alter the patch manually in Vim/$EDITOR – this is what I do when I hit those edge cases.

Ah no - but I will now!

Still, usually what I need there is the ability to leave a line or two there but don't stage it.

You can also press 's' to split in some cases.

What is the use case for 'seeing all information at once'. Normally you want to see something specific, in which case a terminal allows you to see that specific information faster than a GUI.

If all information is already on the screen I am faster moving my eyes to the spot of interest than typing the command (or even a single letter alias).

I guess you would not want to edit a text file of which you could only see a single line at a time.

>What is the use case for 'seeing all information at once'.

Projects can be messy and sometime you really need a bird's view of what's going on with all those branches\merges etc.

GUI also makes it easy to cross-reference between branches, automatically pull submodules, see/do all sorts of things without keeping crufty cli args in your head. I mean, the latter is huge.

I felt a certain bravado in uni for always using the cli that I see among other HNers. As I get older, I couldn't give less of a damn. Scrolling manpages to find an re-remember the unintuitive cli arg I need vs just clicking a button that does it? I prefer the latter. The former is always available if I need it.

The few times I have to drop into cli git are the things I always have to look up anyways, like git-reflog.

1. Do you really need that? It looks good, but how useful it is? I usually only care about my branch and the branch I like to merge in.

2. Yes, that was the only reason I have used git GUIs, but most modern editors have these features built-in.

I find a git-gui is useful to visualise complex workflows, merge mistakes that have been pushed to the repository, and relative status of various branches simultaneously. That, and the per-chunk/line staging is very useful to do visually, can add/remove lines from the index and see exactly what is going to change on what files (without paging through millions of git diff pages).

All of this is possible with the terminal tools, but made much easier with a GUI. It also makes it possible for non-experts to fix problems without just blowing away the repository and repeating work.

I'm still using GitX(l) on mac, it keeps dying and being resurrected as a fork, I've always found it the perfect balance between "too simple" and "too complex", and I can just launch it from the terminal "in context" when I need it.

Yes, irreplaceable! Still using GitX mostly for creating partial commits by picking the exact lines/blocks that go into a commit.

You can use the GUI as a complement. No need to commit 100% to command line or 100% to GUI.

I rely a lot on visualisation to understand things so I tend to like a nice Git GUI. Although some stuff like rebase -i I found it handy to do it in the terminal.

> You can use the GUI as a complement. No need to commit 100% to command line or 100% to GUI.

This. Personally I handle most of Git's CRUD operations through the command line, but to analyse logs and branches and navigate through the depository's history, I find gitk to be an invaluable tool, albeit ugly as sin.

Another "+1" for this approach. I usually default to the CLI for almost everything, however some repositories which have a really messy history I prefer to view the history in a GUI for to speed things up a bit. I'll also sometimes use a GUI if I want to commit hunks of large files as moving through the files and seeing the full context is often a bit easier.

I still always prefer the CLI and will use that first, but I'd feel silly dying on that hill for every situation.

I don't consider a git UI to be complete unless it has interactive rebase support (ie, the ability to squash commits together so the history looks like 'implement X', rather than 'implement X, 'fix X', 'minor typo on X', 'add additional unit test for X').

Command line is great if you prefer it, but Fork, SourceTree and Tower all have interactive rebase support. Here's me using Fork:

https://twitter.com/mikemaccana/status/1237708418124742656?s...

I really want a hybrid command line/gui git client. Either a GUI app with a terminal front and centre, or a command line tool that has some commands to use UI style things.

I hacked together a bash script that prints out all the branches and lets you click on it to switch to it and it's been pretty useful, just wish I could be bothered to make it properly with more features.

Both of the GUI's I've used: Kraken and now Sublime Merge work very well in parallel with the CLI. I just have a terminal open next to the GUI and switch between them depending on what I'm doing.

Much rather not have a terminal in these apps. It'd probably not match 100% my normal terminal and would slow me down.

Agreed I think some hybrid is the answer. As a CLI user I've tried to get used to git GUIs several times and keep going back to the command line because I always get the feeling like I am not 100% sure what it's doing or going to do. I also find it annoying to have to understand yet another set of primitives / keyboard shortcuts etc., when I've already got git's.

I would love GUI tools to complement the command line, instead of replacing it. Already I use the CLI 95% of the time, and launch gitk for that 5% when I really need to see the commit tree graphically. Usually before a merge is the only time I do this.

I wonder if that's a way forward.. a graphical equivalent of "tab completion" when you are trying to write out a command. Instead of a GUI that tries to make git "simpler" by hiding the command-line, how about something that takes the git command you are already trying to write, and helps you write it, e.g. by showing you results of a dry-run on the fly.

GitExtensions includes a terminal and shows the commands it runs and I recently discovered the GitGraph extension in VSCode which allows having a terminal open at the same time. There's more text focused ones like Magit or Tig, I haven't used them personally but from reading the manual of Magit it looks like it can [1] and Tig allows for setting up custom commands [2].

1. https://magit.vc/manual/magit/Running-Git-Manually.html

2. http://jonas.nitro.dk/tig/manual.html#external-commands

Have you tried tig [1]?

[1] https://jonas.github.io/tig/

What does it have to be integrated in one app? Every git client (of the ~dozen I've used) stays synchronized. I regularly use a git GUI, terminal, and a client integrated in my ide, and it doesn't really matter where I do an operation, they all update near-immediately to show the new state.

I don't want a git client for exactly this reason. I wouldn't mind a staging / commit client though, or a client that visualizes the branch situation though.

I wish people who made these things didn't start off with the implicit belief that they need to try to replicate every feature of the git client in a UI.

This is exactly how I use all of these tools. I've not found one that doesn't work well like this - just have it open next to a CLI. I use the GUI for staging, committing, and occasionally resetting branch pointers or cherry picking. Everything else I do with the CLI.

That’s how I use SourceTree and now Fork. They are really good for the daily work like staging and showing diffs. But their use is questionable for other operations.

Seems a bit premature to say that you don't want X when the enumeration of the things you do want are the things that people use X for.

The only thing I use a GUI for when related to git is a 3-way merge. The built in merge tool with a Jetbrains product is pretty good.

There are some other features like the git highlighting in a file is a quick and easy way to see how the code has changed without leaving, but anything besides a merge conflict is done on command line

I use SourceTree, and the command line for some stuff. I have a dual-stream methodology that isn’t GitFlow, and isn’t supported by SourceTree, so I do need to use CLI. I wrote a couple of shell scripts to handle some of the repetitive stuff.

I’m a big believer in high-quality GUI. I’ve used CLI that would have a lot of folks whimpering under their desks, and don’t miss them at all.

Bad GUI is worse than CLI, though. I won’t mention the product, but I tried another fairly well-known “buzzword-compliant” GUI client. For the first fifteen minutes, it was great. Then I tried something off their beaten path, and the dumpster started smoking.

SourceTree has a relatively spartan interface, but also updates rapidly, which is important for when I switch over to CLI.

high-quality GUI

Back in the day when SourceTree had the original built-in multiple repsitory overview it had something no other tool had (I think) and for the rest it was workable, but slow. Then they basically rewrote it, replaced the whole UI with something which was slower and less clear and did not even have the repository overview. I still don't understand why. Plus it still had the annoying problems where you'd be rebasing on the CLI and that would fail because at the same time SourceTree had the repository open. tldr; I admit I don't know it's current state, but at least when I left it it was not exactly a high-quality UI.

Anyway I ditched it for SublimeMerge around that point and even though it lacks certain functionality I didn't go back. Main reason is probably that the UI looks clear, has good diff/staging and proper keyboard support and a command palette. But just like other tools, it's not for everyone.

Pretty much every development utility that I use (especially Xcode) is buggy. ST is no exception.

Like most developers, I've learned where the potholes are, and have warning cones around them.

I'd love a nicer GUI, but, like I said, my experience has me a bit gunshy about using other stuff. I've had Tower for a while, but seldom use it. It's a great app, but the GUI actually gets in my way a bit.

My favorite text editor is BBEdit. I've been using it since last century. It's kept up with the times, but has a much more spartan aspect than editors like VSCode and Sublime. I like its RegEx support; which I use all the time.

I’ve made the same observation too. At one point I was using the guis for the simple stuff, and resorting to the command line if things break. But using the git cli tools is a skill that is very easy to forget, and by the time I got to the weird edge cases, I was pulling my hair with frustration on both myself (for forgetting) and the guis (for actually aggravating the problems)

From the on I resolved to only use the cli, and over time it has become almost as easy to navigate as the guis - all the different cli tools are actually quite great when you get used to them.

The flip side is that I feel comfortable going deep and resolving all the weird edge cases as I can drop to as low level as I wish.

I do all my commiting and most trouble-free pull-/pushing with a GUI. When merging/rebasing becomes more non-trivial I'm beginning to resort to the CLI (and sometimes SmartGit or git-gui for hunks).

I like to use GUI’s occasionally to as a way to see a visualization of the branches.

This has absolutely been my experience. The minute anything weird happens or I need to do something unusual I have to drop into the CLI anyway. So I just learned the CLI. YMMV.

Git is so simple that you don't need a gui for the normal day-to-day stuff.

And if you are fighting with the complex stuff, you are probably doing it wrong. Then no GUI in the world can help you.

Not sure if it qualifies as a GUI, but I’ve found magit increases my productivity with git.

> Git is so simple that you don't need a gui for the normal day-to-day stuff.

It really depends on what you mean by day-to-day operations.

If all you do is checkout code, create ephemeral branches that either get deleted or are merged into another low-traffic branch or are simply pushed to a remote git workflow system, sure you don't need a GUI for that.

But if you need to traverse branch history and compare changes and do three-way merges and audit changes and track logs to a specific file within a repo... You are far better off with a GUI.

But how many fall into the second category? 5% of all users?

Quite a lot more users .. but not every day or even every month.

> But how many fall into the second category?

Everyone who has to fix bugs and maintain software?

It's possible to do it without, so no.

I'd estimate that most of my time interacting with SCM (I use perforce) is spent looking at history and diffing/merging, rather than checking out/creating branches. Checking out is so simple that it doesn't matter whether you use a GUI or not.

On the other hand, I haven't been in the first category since I was unemployed and only worked on side-projects.

Once I worked with teams, I started encountering things like difficult merges, long-running divergent branches, etc. that make GUI useful.

If there are more people in the first category, it's only because anyone can start a solo repo but only a subset of people work on teams.

Either way, who cares? Use what is useful to you.

Throughout these comments is this weird assertion that other people are using the wrong tool unlike us enlightened HNers. It's like people get offended that others prefer other tools. As if it's like "What, is my cli git preference not good enough for them?!"

I'm low-key convinced that's what's actually going on in all these cross-examinations.

Git's internal model is fairly simple. Git's CLI is a toxic dumpster fire. What makes it usable is that 95% of the time you only need 5% of the CLI, and that 5% -- while nonsensical -- is small enough to memorize.

Reply on news.ycombinator.com