Hacker News Reader

Comment by Vlaix | Hacker News Reader

Serious question, never used a git GUI in my life, is there a practical point to it ? I just can't see myself doing it without zsh, my nested .dotfiles, fasd and so on. And worst case scenario, I can always git them back.

View on HN

Believe or not, there are a number of cases where you can work faster in a GUI than the CLI: many operations on the topology of the repo for instance. See somes examples at http://gitup.co/.

Disclaimer: I made GitUp for that very reason ;)

Looks awesome, any chance of a port to Linux? Perhaps via GNUStep?

If you want to visualize the topology of a nontrivial git history, It's several times better in a gui than as a tree drawn using slashes and pipes in a shell window. Compare a nice graphical tree with something you might get from "git log --graph --oneline --all" or a similar command. The shell window just isn't up to the task of drawing nice things, just like it doesn't show pictures very nicely by converting them to ascii.

If you want to see side-by side diffs that's also a lot better in a nice text editor than in a text window. Getting balloon tooltips when hovering commit hashes hidden in a gutter etc. allows more information to be fit onto the screen.

The reason you use a graphical UI is because a text ui doesn't fit all the information you want to show in a good way. Most git tools might not need show or draw a large amount of information (push/pull/commit/...) but some do (blame, log --graph for example).

Not everybody is as comfortable in the CLI as you are. I prefer graphical git "tree" views over the CLI-drawn, but other than maybe that, no, it doesn't sound like there would be a point to it for you.

The lead tech at one place I work at uses the commandline for his own commits, but a gui app (can't recall which one) for manipulating merges and pull requests, as it more reliably deals with issues in his experience.

To be completely honest, I also do it like this at the moment, using Kdiff as a merge tool. I've been thinking about moving over to Ediff, but I'm lazy.

I use command line for the majority of operations. For committing, especially when partially committing a file, I'll use the GitHub app.

I honestly have no idea why people would want to have to click buttons for this stuff.

The one exception in my case is 3-way merges. I handle those in Meld, which I find to be better suited than any of the integrated threesome tools in these git GUIs.

Even that I could probably do better in emacs if I set it up.

In my situation I use gitg to add changes by chunks or lines, I think that's much more faster than cli. But gitg is hard to compile on Ubuntu lts if you want newer versions, I wonder if there is a good alternative?

I generally do that sort of thing(staging/destaging lines and chunks) in my editor. If I could shift the merge tool stuff into my editor quickly I would do that as well. The reason is that it reduces context switching and difference between environments: sure, I could spend hours making the fonts, colours, and keybindings the same between the git gui and my editor; I could get really good at switching to the window; etc. But even a slightly worse version of it in the editor is going to be way less work.

At least, that's how I see it.

Also, I'm sure there must be a PPA or something for gitg on Ubuntu, if you really like the tool.

There are Packages in Debian experimental

Reply on news.ycombinator.com