9 ms·

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/s

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.

panpanna 6y ago
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.
- wkz 6y ago
  Not sure if it qualifies as a GUI, but I’ve found magit increases my productivity with git.
- rumanator 6y ago
  > 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.
  - panpanna 6y ago
    But how many fall into the second category? 5% of all users?
    - hombre_fatal 6y ago
      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.
    - pjc50 6y ago
      Quite a lot more users .. but not every day or even every month.
    - rumanator 6y ago
      > But how many fall into the second category? Everyone who has to fix bugs and maintain software?
      - recursive 6y ago
        It's possible to do it without, so no.
    - maccard 6y ago
      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.
- dreamcompiler 6y ago
  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.
Wowfunhappy 6y ago
I like to use GUI’s occasionally to as a way to see a visualization of the branches.
pydry 6y ago
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.
- Ididntdothis 6y ago
  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.
- hombre_fatal 6y ago
  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.
- IneffablePigeon 6y ago
  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.
chrisan 6y ago
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
laszlokorte 6y ago
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)
- ProZsolt 6y ago
  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.
- richardwhiuk 6y ago
  `git add -p` is pretty fast for staging parts of files
  - konart 6y ago
    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.
    - skrtskrt 6y ago
      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.
      - dbalatero 6y ago
        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.
seer 6y ago
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.
- mbeex 6y ago
  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).
misnome 6y ago
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.
- sfvisser 6y ago
  Yes, irreplaceable! Still using GitX mostly for creating partial commits by picking the exact lines/blocks that go into a commit.
ChrisMarshallNY 6y ago
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.
- stinos 6y ago
  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.
  - ChrisMarshallNY 6y ago
    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.
flr03 6y ago
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.
- rumanator 6y ago
  > 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.
  - bluehatbrit 6y ago
    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.
- nailer 6y ago
  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=20 https://twitter.com/mikemaccana/status/1237708418124742656?s...
jon889 6y ago
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.
- aarbor989 6y ago
  Have you tried tig [1]? [1] https://jonas.github.io/tig/ https://jonas.github.io/tig/
- gregmac 6y ago
  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.
- wjdp 6y ago
  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.
- radarsat1 6y ago
  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.
dreamcompiler 6y ago
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.

panpanna 6y ago

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.

wkz 6y ago
Not sure if it qualifies as a GUI, but I’ve found magit increases my productivity with git.
rumanator 6y ago
> 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.
- panpanna 6y ago
  But how many fall into the second category? 5% of all users?
  - hombre_fatal 6y ago
    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.
  - pjc50 6y ago
    Quite a lot more users .. but not every day or even every month.
  - rumanator 6y ago
    > But how many fall into the second category? Everyone who has to fix bugs and maintain software?
    - recursive 6y ago
      It's possible to do it without, so no.
  - maccard 6y ago
    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.
dreamcompiler 6y ago
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.

Wowfunhappy 6y ago

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

pydry 6y ago

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.

Ididntdothis 6y ago
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.
hombre_fatal 6y ago
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.
IneffablePigeon 6y ago
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.

chrisan 6y ago

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

laszlokorte 6y ago

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)

ProZsolt 6y ago
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.
richardwhiuk 6y ago
`git add -p` is pretty fast for staging parts of files
- konart 6y ago
  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.
  - skrtskrt 6y ago
    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.
    - dbalatero 6y ago
      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.

seer 6y ago

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.

mbeex 6y ago
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).

misnome 6y ago

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.

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

ChrisMarshallNY 6y ago

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.

stinos 6y ago
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.
- ChrisMarshallNY 6y ago
  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.

flr03 6y ago

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.

rumanator 6y ago
> 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.
- bluehatbrit 6y ago
  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.
nailer 6y ago
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=20 https://twitter.com/mikemaccana/status/1237708418124742656?s...

jon889 6y ago

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.

aarbor989 6y ago
Have you tried tig [1]? [1] https://jonas.github.io/tig/ https://jonas.github.io/tig/
gregmac 6y ago
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.
wjdp 6y ago
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.
radarsat1 6y ago
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.

dreamcompiler 6y ago

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.