Guitar – Git GUI Client | Hacker News Reader

Guitar – Git GUI Client

github.com

232 pointsapp4soft187 comments

I think the author should be applauded for developing a native application instead of yet another electron app. Having a gui for version control is very useful, especially for working out branches, merging etc. The edge cases can always be handled from CLI. For reference, I worked on Perforce for many years and having P4Win instead of the p4 command line was a godsend for most cases because of the hugely complex underlying tool chain.

It's a Qt application in this case. IIRC, Qt draws controls itself, rather than relying on native platform controls.

Even so, Qt has a hell of a lot less of a footprint than Electron.

I'm pretty sure it can (and might by default) use native controls on macOS, and I've heard of that possibility on other platforms as well, but I'm not sure how far that's gotten.

"more or less", on Mac it will sometimes use dummy OS controls for the sake of rendering, e.g. like here : https://code.woboq.org/qt5/qtbase/src/plugins/styles/mac/qma...

But it cannot just use native controls all the time as it generally supports more features than what is available on a given platform, so there has to be a kind of emulation.

AFAIK it's possible to use native controls too with Qt these days. I don't know if this project is doing so (probably not).

Why are people still not liking electron apps? Are they using machines from before 2010 and some system resources is a limiting factor?

Also, I would vastly prefer electron apps instead of using a native toolkit that's not following the interface guideline of the OS that looks to be using free icon set from the 90s instead of using Font Awesome or similar.

> Are they using machines from before 2010 and some system resources is a limiting factor?

This is the most annoying thing with developers: many of them believe that a normal laptop from around 2010 is "underpowered" and everybody's using the latest macbook pro or some high-end device. But the majority of people use average computers with 4-8GB RAM and some random CPU. Most machines don't run on high-quality fast SSDs.

Also, the app is perfectly following the user guidelines of usable OSes: pre Win8 Windows and pre Gnome3 Linux. Those icons from the "90s" make sense and communicate their functionality well, because they adhere to some convention and are not pure fluff like FontAwesome et al. are. The sheer ignorance of dev community wrt. usability both in design and in performance is sad. Desktop is where people get work done and the bastardized mobile interfaces Win8, Gnome 3, and Electron brought there are nothing but an obstacle. Macs seem to not have gone to that direction yet, but slowly "advancing".

It's telling that none of the widely used IDEs---Even Android Studio or XCode---don't adhere to these bullshit "interface guidelines".

I have a vastly overpowered machine - i7 6900k, GTX 1080 and electron apps definitely don't feel as snappy as apps using traditional GUI toolkits. They almost all have typing latency, loading screens, etc... a pain all around.

My blood pressure decreased by a huge amount the day I replaced discord & slack by ripcord... and it's also much better in term of UX when you are on a ton of different instances.

e.g. the difference in responsivity is huge : https://streamable.com/ori2yg

and ripcord does so in 87 megabytes of RAM with while slack does it in 758 : https://i.imgur.com/xivK3gr.png

and that's not counting that I would also need discord next to it. I had to buy 64gb on that machine because of all this fuckery - add a few additional work workspaces and a 16gb machine which is already more than what the general public have and it's unuseable. Just checked in the website of the biggest french retailer, and 7 out of the 10 most currently sold laptops have 8 gigs of ram for instance.

What's your opinion on VSCode. It feels pretty snappy on my laptop, from what I understand it's written in electron

it's here : https://news.ycombinator.com/item?id=22948981

Out of curiosity, why do you prefer a native app over an electron app?

Other commenters are rightfully pointing out the continued performance issues, but just as important for me is the platform citizenship of electron apps.

The glut of new ones I use for work on macOS: VSCode, Slack, Notion and Height all have different keybindings than any other apps, some completely disable command+? which I use to find/learn commands for operations I don’t already know. Some just don’t use the menu bar at all. Layout is awful in them, like slack threads being a sliver of the right side of the window, or notion’s usable area maxing out at 800 pixels, or height’s window being fixed to a minimum of 800. Some don’t respect auto dark/light mode. Notion has completely upended many tried and true patterns from word processing. Links take you to the browser based version instead of deep linking to the app.

Of course there are some things I do like about each app, but for me they aren’t worth the tradeoff for the ramp up time on a new product coupled with the annoyances I encounter when using these new apps. I can get things done just fine in a github repo full of markdown, or apple notes, or email, or Xcode, or textedit or sublime text, and on and on. Not to forget the venerable command line. I think the one web app I legitimately enjoy using is trello.

Not GP, but Electron apps to me have a specific “smell”. When you run one, you get to know it’s an Electron app without prior knowledge of that fact. Slow launches, massive memory usage that initiates thrashing, standard OS keyboard bindings not working, actions within the app being sluggish (especially if this is not the only app running and there are other apps using some RAM), and sometimes several crashes too.

I know that there are some Electron apps that behave well and perform well (responsiveness and RAM usage), but those are in the minority. One could always run a bloated Electron app as the only foreground app on the system and give it more resources, but the usability compromises are hard to get over if you’re someone who likes learning and using keyboard shortcuts and other OS specific interactions.

Dunno about the parent, but for me it's like getting a big, fat, ugly truck to drive to the grocery store every week.

There's electron, and there's electron-type apps.

Vscode is pretty snappy and relatively light to the point it's not prohibitively expensive to run it, for example.

Either you use Electron or you don't.

VSCode is handling a lot of the heavier stuff in C++, but it's still an Electron app, with the sluggishness that comes with it. Compared to things like nvim or sublime text 3, VSCode performance ranges from "meh" to "ugh".

It's true that VSCode is somewhat usable (unlike Atom). However, it is not impressive, despite so much effort being put into its performance (including a vast amount of core code being written in C++).

For this reason, I take VSCode as the perfect counter-argument to Electron: It shows you that the absolute best case is somewhere between poor and mediocre responsiveness with pretty high resource consumption for the task.

(Anyone who finds VSCode to be snappy is either too used to the sluggishness of web, unfamiliar with how a responsive application feels, or has just thrown so much hardware at the problem that it ends up being decent.)

I mean I use vs code daily and don't think it's any less "snappy" than a native app. Quite the opposite really, Chromium's rendering engine is faster than most native cross platform toolkits. The memory consumption doesn't bother me either or come anywhere close to bottlenecking me, because I'm a professional using professional hardware.

Sublime is also pretty featureless compared to VSCode as well.

> Chromium's rendering engine is faster than most native cross platform toolkits.

Which toolkits are you referring to, and do you truly just mean the renderer, or the entire engine?

Chromiums renderer is pretty fast. Not as fast as direct rendering like Sublime Text does, but for very complex scenes, it will beat Gtk and Qt.

However, it's expensive to build scenegraphs for it (needed on every change), and partial updates are far more expensive than they need to be.

The end result is that, for something like an editor, Gtk and Qt will beat Chromium for responsiveness by a large margin, despite having much less performant renderers for the time being.

(You can get around some of these costs by using WebGL of course, but if you're doing manual rendering you have already thrown most of the reason for Electron out of the window, so why not do it natively where it will be even faster?)

> The memory consumption doesn't bother me either or come anywhere close to bottlenecking me, because I'm a professional using professional hardware.

This is an awful argument. That I have beefy workstation machines doesn't really matter when I'm usually mobile on a low-power laptop.

The difference between using VSCode and sublime/vim is several hours of battery life, and the difference between a comfortable lap and a warm lap.

This idiocy of "it's fine, there's enough resources" is why my colleagues expensive MacBook Pro's are hyperventilating 24/7, and it's a problem for poorer individuals that might not afford a powerful machine.

> Sublime is also pretty featureless compared to VSCode as well.

Matter of taste.

Sublime Text still has a very long list of plugins, and certainly does everything I will ever need an editor to do. I see no reason to pay the penalty of Electron to get support for NyanCat cursor plugins.

VSCode is also pretty featureless if you compare it to vim, and if we pull Emacs into the discussion, VSCode ends up looking more like nano/Notepad.

Its too early in the morning for me to get into a flamewar about this.

So all I'll say is that I get a lot of value out of VS Code as a tool, and I don't think it's slow. I think every point you bring up comes from a lack of experience and knowledge of the tool/platform, and it's not worth arguing about online.

I'm not saying that VS Code is not valuable as a tool - that would be a stupid thing to argue over.

I used VS Code for about a year, and occasionally revisit to reevaluate. Hell, I even gave Atom a (rather unwarranted) fair shot.

What I am evaluating is just performance and resource consumption, which is much worse than it needs to be due to the design choice of using Electron, which has little to nothing to do with the functionality it provides.

For me, the performance makes it uncomfortable to use. Others less fortunate will be experiencing something much worse than I am.

I agree that VSCode is not "slow," at least not when you get used to it and definitely not in comparison to other Electron apps. I used Sublime Text 3 for a long time before Atom became popular. Immediately, I noticed that Atom was nowhere near as snappy as ST3, and was constantly hanging even on opening large folder structures.

VSCode was a breath of fresh air compared to Atom and the extension support was even more impressive. But very recently when I found out about the Sublime LSP package, I decided to give Sublime another look. The snappiness difference between ST3 and VSCode is night and day. Even though by no means does VSCode feels "slow" for my day-to-day work, the small speed improvements of using ST3 compounds to make for a greater experience overall to me.

I can add that extra heat from laptop on your lap running electron may cause fertility problems.

> I mean I use vs code daily and don't think it's any less "snappy" than a native app. Quite the opposite really, Chromium's rendering engine is faster than most native cross platform toolkits.

it's definitely not. Just adding a `/*` at the top of a file takes a noticeable delay to update the whole text, while it's completely unnoticeable in e.g. QtCreator.

I just took this video on my screen, notice how everything lags in VS Code (left) in contrast with QtC (right) :

https://vimeo.com/410735827

Just look at the scrolling : super smooth on QtC, all janky on VSCode (I let my scrollwheel in free wheel mode in both cases) :

https://vimeo.com/410739729

What's worse, VS Code uses GPU for its rendering while QtCreator uses a software rasterizer, which should in theory perform less well (in practice, GPU font rendering is definitely not there yet). Both use the same backend for C++ syntax parsing (clang) so the problem is not there.

> it's definitely not. Just adding a `/*` at the top of a file takes a noticeable delay to update the whole text, while it's completely unnoticeable in e.g. QtCreator.

Conversely, Qt Creator is rather anemic and featureless when compared with vscode. I mean, it doesn't even support very basic features such as editing yaml or json files, it barely supports any form of refactoring at all, doesn't support any form of project other than the old hardcoded C++ support piggybacking clang, etc.

Heck, supposedly Qt Creator's main build system is cmake, and it doesn't even allow you to add files to a project without having to hand-tweak CMakeLists.txt files.

Perhaps if Qt Creator offered a fraction of the features already provided by a free text editor such as vscode then we could start to compare sub-milisecond differences in paint times. Until then, unnoticeable differences in performance coupled with far more functionalities make it a non-starter.

I don't think any of this is relevant to rendering time.

> and it doesn't even allow you to add files to a project without having to hand-tweak CMakeLists.txt files.

I don't know any IDE which does this well and don't think that this is a solveable problem at all. e.g. where would a source file be added there ?

    set(COMMON_SOURCES a.cpp b.cpp ${SOME_OTHER_SOURCES})

    if(SOMETHING) 
      add_executable(foo WIN32 main1.cpp ${COMMON_SOURCES}) 
    else()
      add_executable(foo main2.cpp xyz.cpp ${COMMON_SOURCES})
    endif()
    
    if(FOOBAR)
      target_sources(foo PUBLIC foobar.cpp PRIVATE baz.cpp)
    endif()

I've tried looking in VSCode to test where it would go but cannot find a command that would add a new file to a CMakeLists. File > New file > save as .cpp definitely does not and I don't see a right-click option that would do it.

> , it barely supports any form of refactoring at all,

c'mon, here's my experience with Qt Creator when comparing with VS Code (with the C++ extension installed):

- vscode: https://vimeo.com/410950170

- qtc: https://vimeo.com/410950345

I'll agree that QtC (https://doc.qt.io/qtcreator/creator-editor-refactoring.html) has less than for instance CLion in the refactor department, but than VSC? Maybe with ten additional extensions or so ? But qtc works from the get-go without needing to go fetch plug-ins elsewhere.

Note also how QtC helpfully tells me bugs and issues in my code along me typing, without making typing slower.

In contrast, I really have trouble concentrating with VSC (and also JetBrains IDEs & VC++) operating latency (and that's on a 8c/16t top-end desktop i7).

>mean I use vs code daily and don't think it's any less "snappy" than a native app

it's objectively worse.

https://pavelfatin.com/images/typing/editor-latency-windows-...

https://pavelfatin.com/typing-with-pleasure/

atom (electron based editor) has the highest latency of all. VSCode isn't listed but here's a benchmark by a random github user: https://camo.githubusercontent.com/7a5b91ed14a0173f861b8478c...

It’s not slow, but it is not responsiveness. Electron has terrible input latency compared to native.

> and don't think it's any less "snappy" than a native app.

I have tried to adopt vs code multiple times and just end up going back to (n)vim, where opening a file is instantaneous and I never have latency when typing, etc.

However I do find Jetbrains' products like CLion/Goland are pretty nice.

From experience... with today's computer having 16GB+ ram, VSCode is fine. But if you start doing dev work on a 2011 Macbook Air with 4GB ram or even 8GB ram, you quickly notice how much memory electron apps consume. When switching between VSCode to something like Sublime, the consumption is 10X improvement. That is my only beef with Electron apps. It is a way to get something cross-platform extremely fast but with ZERO care for how expensive it is.

FWIW, I use VSCode...

I'm looking to edit some text or view JSON quickly, I will always reach for Sublime first because it starts up at least twice as fast.

I like VSCode but also agree. Once you've felt the speed of native, like Sublime Text 3, especially when opening and working with a lot of files at once, it's really hard to use anything else, IMHO

That said, there are use cases for VSCode that don't really apply to ST3, etc

The React Native team at Microsoft does occasional jabs at Electron performance (check their BUILD and IGNITE talks).

I have this hope that they eventually will trigger VSCode's rewrite into React Native.

I’m the latter - a 12 core Ryzen 3900X means even Visual Studio itself feels snappy!

Seriously though, VSCode isn’t bad. I use it on my Surface Pro (dual core i5) without any issues. It’s a nice app.

VSCode is the fastest Electron app, so it's fair to use it for comparison to native apps.

It's slow compared to Sublime Text 3, which is probably the closest alternative. And compared to vim, VSCode is positively glacial.

As long as there's no latency when actually editing text, which is my experience with vscode, I don't think it's that big of an issue. As someone that's moved from vim+plugins to vscode, I'll take the few milliseconds of latency here and there as the price of having an environment where everything just seems to work out of the box, including plugins. Sure vim is snappier, but does it really matter if I have to constantly debug why youcompleteme isn't finding my header files or whatever.

Theoretically that doesn't have to be trade off. Theoretically it's possible to build an editor like vscode with a native interface. In the actual world it doesn't exist for whatever reason, so I'm going to keep using vscode.

Theoretically it's possible to have a not-buggy vim. It's not fair to exclude everyone who is able to configure a more performant editor just because you can't.

Your claim that "in the actual world it doesn't exist" is just not true. Thousands of lifetime vim/emacs users are scratching their heads.

Configuration is maintenance that I'd rather not do, it's not a matter of "can't". I used vim as my main editor for years, and I had it very much configured to my liking. Any time you have to set up plugins for a new language or a new environment though, it can be annoying, which is why I started using vscode as a front-end for neovim. Now I have a nice-feeling well-supported IDE with all the power of vim for editing.

Okay; my response was to what you said, which was that my editor doesn't exist.

> VSCode is the fastest Electron app

I no longer consider vscode to be an electron app. You would need a ton of expertise and lots of c++ to have your electron apps perform anywhere close to vscode (and you would still be slower than native)

I use a 2013 MacBook Air and while I really like Vscode for its features, UI responses are constantly lagging.

Native apps feel like they react an order of magnitude faster.

It's ok, but "snappy" really is the last description I would think of when using Vscode.

I always see Visual Studio Code trotted out as an example of a relatively fast Electron app. I do use Visual Studio Code (for complicated reasons), but if I were to describe it to someone, the first thing I'd mention is that opening a new window (i.e., the `⇧⌘N` shortcut) is incredibly slow. For this action, it's easily the slowest of any application I use regularly, I can count to three before the window appears, a normal application is ready for input practically instantaneously.

Main problem I have is that it keeps using 100% CPU on my Mac most of the times which doesn't make it easy to run Docker/K3s alongside

VSCode makes me want to tear my eyes out.

I don't think this has been mentioned yet, but dark mode on a Mac is very adaptive, and has lots of material which adjusts to the color of your desktop.

Compare these 3 screenshots of the same window (https://imgur.com/a/UNXtweJ) - and that's not a translucent or blurred window, it's just a solid background color. The only change I made between taking those was picking a different desktop image.

When I open Slack, it doesn't match any of the native apps because it doesn't use the native color blending. It's just drawing a different palette of colors.

In this case, I don't know if QT is going to be any better if it is just drawing all of its own controls. There's another native Git client that I use, and it looks amazing and blends right in with the rest of the apps I use everyday.

I don't understand how this sort of question gets pummeled with downvotes. Having developed Qt and XAML applications, I have to say that the DOM approach makes a lot more sense than wrestling loosely bundles of widgets. In the end Qt apps end up with a widget tree, but the path that they take to get there is convoluted and packed with unnecessary fusion of UI responsibilities and data and even business logic.

I don't think end users decide which GUIs they like based on their "DOM approach" any more than they decide what milk they like based on the milking approach.

I'm pretty sure that users like good software with pretty GUIs that are easy to use and navigate around and extend.

DOM-based frameworks make this sort of stuff trivially to implement, and some of them evem come with gesture and animation support out-of-the-box. Meanwhile, feel free to take a look at Guitar's source tree to figure out if that is trivial to work with, and at best it looks like an app from 1998.

https://github.com/soramimi/Guitar/blob/master/src/AboutDial...

Looks pretty much the same as stitching DOM elements to me, and various runtime modifications in HTML-based frameworks remind me of the "put widget into container" code style of Tk. There's even a CSS-based styling support for Qt.

The main difference is that there is easy way to make a visual designer for the QT .ui files, so it's actually even easier to write GUI apps there.

And DOM based frameworks do nothing to ease of use, ease of navigation, or pretty much anything done by end user*. They make it easier on making portable GUI, yes, but that's on developer side, and with significant costs associated to everything, including reputation of the application and developer.

Qt and widget based programs are absolutely not difficult to make. I don't know where this comes from. They are fast and responsive by default instead of laggy and sluggish on a many core xeon loaded with ram. Even using PyQt and embedding python is like a feather compared to electron and that approach is extra easy.

But that's not really the point. How easy is it to make great UIs with them?

How easily can you make a staggered fade and slide in animation? Responsively change layout? Apply complex styles?

That's a good question but what's the point of all this if no one can use the app if they don't have a minimum of 8gb ram? My wife couldn't run Spotify, slack at the same time cause her machine started swapping.

The developer experience is vastly superior in electron and it's reach is massive. There's no denying. But the underlying problems are pretty serious and the people who complain are not just hating for random reasons.

I hope you get how insane it is when your cpu fan starts spinning because of an app that plays music in the background!

So far the pro electron arguments are concerned only about developer experience who generally have beefier specs in their machines.

The lowest common denominator in end user machines are very different and I request you please keep that in mind!

P.S: I'm a web developer and I fully understand how much valuable electron is for me.

> That's a good question but what's the point of all this if no one can use the app if they don't have a minimum of 8gb ram?

Even vscode, which has a gigantic memory footprint due to its plugin system, requires 1GB to run comfortably.

Nowadays you get computers with 4GB of RAM for 60€.

Let's not bother ourselves with irrelevant details.

It's completely relevant. People run more than one application on their desktop computers.

Regardless of what many people say, RAM usage still matters. If every app takes a giant chunk of RAM just to get started ( which many do ) eventually that's going to bite you.

Yes, we do have a ton more resources to work with than we used to, but I'm afraid far too many developers have just stopped caring about it at all -- and that's a very bad thing.

> It's completely relevant. People run more than one application on their desktop computers.

That's great, so that must mean you'll be happy to hear that right now I have two instances of vscodium open, each one running half a dozen plugins, and their total memory footprint is less than 300MB.

Do you have anything relevant to say regarding how much resources are used? Or are we supposed to keep debating if being able to run 40x instances of a text editor is not enough room to work with, or if whether having only 7.8GB of RAM free to run other programs is too restrictive?

I hope this is genius level trolling.

In case it's not: great UI != any of those

This:

> great UIs with them?

is completely opposite to these:

> staggered fade and slide in animation?

> Responsively change layout?

> Apply complex styles?

A UI that can change layout to accommodate your window size and in which UI elements don't confusingly jump around when you click something but transition is bad? I'd like to read about your idea of a good UI.

You can't! You can really only make QT apps with them. I think it's funny that people see the lack of features and visual distinction as an advantage.

Qt apps can have lots of features.. Did you never use KDE3?

> I'm pretty sure that users like good software with pretty GUIs that are easy to use and navigate around and extend.

I don't know about other users, but I like good software with functional UIs that are easy to automate and extend. In my experience, that's definitely _not_ Electron-based UIs. It's also not most GUIs either for that matter.

I absolutely do _not_ want "gesture" and "animation" support. Gestures are a hack for a shitty touch-screen input with zero tactile feedback. Animation is just a power hog for, like you said, a pretty interface. I don't want a pretty interface if it costs performance, costs battery, costs usability.

Plenty of people seem to not use Electron apps despite their sometimes superior UX, because the inherent problems with it are so off putting that the improved functionality doesn’t make up for them.

That said, if superfluous animations are a big part of the benefit, you can count me out in any case.

Qt has widgets. DOM approach doesn't have widgets but <div> elements stitched together to pretend to be something else than boxes of text.

> <div> elements stitched together to pretend to be something else than boxes of text.

As a Norwegian <div> makes perfect sense, as "div" is a common shorthand for "diverse" meaning "various" or "miscellaneous". At least that's what I always think of when writing <div>.

It's short for a "content division" being a generic reflowing container.

For me, something being an electron app isn't the worst thing in the world. What is problematic is the JavaScript ecosystem.

I use and occasionally contribute to a distro that's very strict about all dependencies of an application also being packaged in the distro. That's just infeasible for most JavaScript apps these days; most that I've seen have on the order of 500-1000 dependencies.

I do not have unlimited ram

To put your question in a footwear-oriented perspective: Out of curiousity, why do you prefer shoes made of nylon or leather over those made of lead?

Being a dad and highly prone to excessive punning if given half a chance, it almost hurts that this is not a GUI for tar.

As a developer I love good GUIs and should check this out.

It exists and was active till 2013 cwww.edenwaith.com/products/guitar/

If some likes to push a homebrew cask package for it, here is a possible source:

  cask 'gui-tar' do
    version '1.2.4'
    sha256 'e11177b99a01d5cff666f68072fd2145cccda4678a8a98203d97929cbe53dea2'

    url "http://www.edenwaith.com/downloads/guitar.dmg"
    name 'GUI Tar'
    homepage 'http://www.edenwaith.com/products/guitar/'

    app 'GUI Tar.app'
  end

I had a similar thought. This project should have been named "Gitar".

"guiTAR is a generic archive tool, written in GTK+/Gnome, supporting plain tarballs, tar.gz, tar.bz2, slp, zip, lzh, arj, and rar format. "

https://www.freshports.org/sysutils/guitar/

http://web.archive.org/web/20020401054755/http://artemis.efe...

Well, I went a different way at first.

I was trying to figure out if it used git somehow to manage creation/rendering/storing of guitar tabs or something.

I kept looking for any images of guitars or screenshots of standard music notation and tab.

Then I finally read the title and part of the README.

:-D

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.

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)

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.

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

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.

You can also press 's' to split in some 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.

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

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.

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.

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

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.

Have you tried tig [1]?

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

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.

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.

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

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.

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

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

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

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.

As an alternative I highly recommend Fork, a life/time saver when working in Windows, it's a high quality (and native) Git GUI client.

Guitar is also good too, and are thankfully both native!

[0] Fork - https://fork.dev

Fork is closed source, and costs $50.

It is nagware - will work forever but with a nag screen (like WinZip back in the day), and IMO it is definitely worth a one time fee of $50 if you don't mind using closed source.

But it is not quite the same category as Guitar.

I actually didn't know that Fork can be bought! I installed a Beta version a while back, upgraded regularly and never have been shown a nag screen. Gladly paid for my license a few minutes ago.

Fork is one of the few pieces of software I used in beta where I thought, "You're not asking for money right now, but you seriously need to let me pay you for this."

Long time mercurial user here. When I started using git, I found git cli and other UI clients very confusing. Followed many tutorials, etc. But I couldn't stop thinking in terms of hg and transition to git. Fork saved my day. The UI is distraction free and feels like a perfect wrapper over git porcelain than git cli. I started looking into what commands are executed on the UI and repeated the same on Linux to understand and learn more. I'm now comfortable with git cli because of Fork.

Great on macOS too. And it is native app on both platforms, no electron.

thanks for recommending fork.dev.. just installed on windows and looks sleek! it's seems freeware.. i dont know how often does it show that popup people are talking about

Sublime Merge is this but... sublime: https://www.sublimemerge.com/ it's amazing and pretty similar

I've found sublime to be not so sublime. It beats everything in terms of speed but I'm not a fan of the design and it's woefully lacking in customisation and doesn't support a lot of the git options. On Linux it's my only choice for a good GUI but on mac and windows I much prefer fork.dev which is almost as fast and is very feature rich and looks great

Fork is definitely my fave on Windows too. I’ve heard people say good things about GitKraken but the UI really didn’t click with me for some reason. Sourcetree (on Windows at least) is slow and a real memory hog.

GitKraken is horribly slow too. I've only ever been happy with flow (which I've now paid for cause I love it) and Sublime Merge which I still use on linux but am less happy with

> fork.dev

That looks cool! Personally I love the simplicity of both Sublime Text and Merge so I gravitate towards those (I don't really care/need about customization)

I was doing a trial run of git GUIs cause I'm much more productive with one and I landed on Sublime which was good but lacked a lot of options and I don't think still allows for adding custom commands. I was also extremely miffed when it took months for an update to come out to fix one bug I'd found and was irritating me to no end (I forget the specifics now). For me the update cycle is also extremely slow and the price is prohibitive.

I wish I liked it more but I've settled on fork now. Good you're happy with sublime. I'll check it out again once it's rounded off with more features

This looks awesome, and fully native too it seems! I'm not a fan of the electron style git GUIs that don't really fit into the OS.

In the case of OP, Guitar looks a hell of a lot better on Linux installs. I suppose that's due to QT theming.

> On Linux it's my only choice for a good GUI

Smartgit works very well on Linux

This is what I'm currently using but I'm not totally loving it.

I landed on it because the speed is unparalleled, but there's a few too many quirks (recent repositories never seems to work for me) and the UI is almost there but it's too hard to instantly see the status of things, particularly whether things are staged or not staged.

I'm still using GitX-dev[0], mostly for doing commits and visualizing branches. Although lately I've been committing directly from Visual Studio Code.

For more complex operations nothing beats the CLI.

[0] https://rowanj.github.io/gitx/

> For more complex operations nothing beats the CLI.

I think that's only because most of the UIs are so bad! Manipulating a graph is something that I think inherently is actually quite visual.

GitUp[0] has excellent graph-editing facilities, and has replaced almost all of my git command-line machinations.

Alas, it's semi-abandoned and left in a perpetual state of 90% doneness...

A little challenge, if you're interested: Give some git manipulations you would do on the command line, and I will show you how to do it more easily in GitUp, or concede defeat. :-)

[0] https://github.com/git-up/GitUp

No takers? :-)

GitX still had one of the best visualisations. But it bugged so often I had to replace it with Fork https://fork.dev

+1 to Fork. It's really an amazing client that has a "freemium" model similar to Sublime (you don't _have_ to pay to use anything).

It's still actively developed and I love the Branch favoriting feature (which I haven't see in any other GUI).

Oh, I didn't know it. I'll try, and if it's good I'll gladly pay for it :)

I have started using lazygit, a CUI, or console user interface. It runs in my terminal window but gives me the same broader perspective a GUI does. Looking at the screenshots of Guitar, which look amazing, I realize with lazygit I get 95% of the benefit of a GUI but in a package that does not disturb my workflow.

https://github.com/jesseduffield/lazygit

There are edge cases that lazygit does not handle well, but it is a simple matter to type "q", bop back to the terminal and run whatever git command and get on with life.

The most well known TUI/CUI for git is probably tig: https://jonas.github.io/tig/

Emacs users will always have magit, but for everyone else it can be handy to use GUI tools for interactive staging and interactive rebase.

Which cases does lazygit not handle well? Asking because I'm working on something similar, although probably simpler and with less features [0].

[0] https://tomas.github.io/jix

When I think about the situations where I don't use lazygit, it is when I am unsure of what I am doing and therefore unsure what lazygit is doing. Almost everything I normally do with git, I can do with lazygit, but there are things I am not confident about. Squashing commits versus picking and do they go up or down, etc? Rebasing. I tend to go to command-line git in those cases, not because lazygit does not handle them but because I don't. :-)

The crucial advantage of lazygit for me is the "situational awareness" I gain in one window - more than any added functionality. The other take away is for your tools to be utterly trustworthy. :-)

Gotcha, thanks.

I--for one--love a GUI. Especially for git. I also love a good pun, so I'm definitely going to try this! It's gonna be tough to beat VS-Code and Kraken though.

GitKraken has been a godsend, I have been really spoiled by it. Managing big repositories has become a breeze thanks to the visualization techniques it uses. If only the company behind it weren't so questionable about their privacy and monetization policies. I am still on the fence on the product.

What issues are there with the privacy policies? Did I miss something?

The founder has some controversial views on how to develop the product, this includes more cloud integration.

https://old.reddit.com/r/git/comments/59j0yq/gitkraken_is_no...

On top of that GitKraken is closed-source and in the past there were concerns on telemetry collection: https://old.reddit.com/r/git/comments/4dgpgd/gitkraken_data_...

Nothing major, which is why I am still using it, but definitely enough to make you wary.

From all the git GUI tools I like VS Code the most. I know it is IDE, but it is very fast, free, open source, multi-platform, and has amazing plugins for most use cases.

Other than that, most frequently I use CLI.

I also find IntelliJ embedded git client to do wonders too.

I am scared of clicking on anything git related in VS Code: redundant items in menus, half translated strings, etc.

Why isn't this name used for a tar gui frontend? :p

I love it. But we’ve got

    man tar

Thank you to the author for making a native application.

I've been using Tower (on Mac) for a long time and I'm happy with it. It's also free now if you are a student: https://www.git-tower.com/students

And if you are not a student it's a subscription: every year you'll pay up 69 or 99 €, "access to Tower ends when the most recently paid-up subscription period ends."

Not so great... (they switched to subscription some years ago, adios amigos!)

Tower is quite literally the only application I'm willing to pay subscription pricing for. It's quality software, doesn't hold my data hostage, and has a steady stream of updates. I'm as adios amigos as you, but I don't think the usual reasons apply here.

Nice tool, will be testing it. Thanks for your hard work

Still haven't found anything better than gitk

That is nice. https://git-scm.com/docs/gitk

Based on one of the screenshots, it looks like Guitar doesn't support word diffing. Sourcetree lacks word diffing as well and has had an issue about it since 2012: https://jira.atlassian.com/browse/SRCTREE-888

> Based on one of the screenshots, it looks like Guitar doesn't support word diffing.

Could you report this feature request to dev?[0]

[0] https://github.com/soramimi/Guitar/issues

Which GUI clients that you know of do support word diffing?

Fork (https://git-fork.com/)

I have Fork, but I don't see any word diffing functionality, unless you are just referring to an additional highlight on the changed word(s)

Yes, that's what I'm referring to.

You can see it in Fork's screenshot: https://git-fork.com/images/diffViewer.jpg

But if you look at Guitar's, you'll see the lack of word diffing, and that makes it take significantly longer to see exactly what changed: https://camo.githubusercontent.com/3c6c338ece93afda723cef575...

Already requested for Guitar. Follow this issue thread.[0]

[0] https://github.com/soramimi/Guitar/issues/76

Thanks!

Haiku is a nice welcome.

Though IMO using Qt for its GUI instead of the native lightweight Haiku ones is missing the point of Haiku a bit.

Cool effort and props for the native app, but I've been using GitKraken for over 2 years now. I know all the console commands I'll need because I've used them for so long, but I can't be bothered with them anymore. GUI and merge editor is so nice to have.

I never really felt a need to use a GUI client for Git. I think they all hinder understanding of Git instead of helping. However I use Tig (console client) extensively for read-only Git operations. For everything else, there is Magit (Emacs Git client).

Is there a way to connect Guitar to a remote server.

Or, are there other Git GUI's that work over SSH?

I can use VSCode, but it is not really a Git GUI, and doesn't satisfy my needs.

depending on your OS, there are ways to mount a remote ssh location locally, which means that you can use any GUI you want (but it will be slow).

for example: https://www.redhat.com/sysadmin/sshfs

> Is there a way to connect Guitar to a remote server.

Please, ask dev on issues tracker.[0]

[0] https://github.com/soramimi/Guitar/issues

is there any comparison to existing git clients? I am currently happy with git extensions and KDiff (for resolving conflicts)

Sadly no (portable) ZIP package for Windows :(

If you really need it — create feature request.[0]

FTR, Actually installers for Windows available only for Win32[1], so you may want request Win64 builds too.

[0] https://github.com/soramimi/Guitar/issues

[1] https://files.soramimi.jp/guitar/

aur/guitar-git. Just used it to grab its own source from Github. Love it. This stays.

Just use the cli - it’s faster and more productive

Reply on news.ycombinator.com