Comment by swalsh
7 years ago
I use the git CLI. I do it for one reason. I know exactly what i'm doing on it. I have nothing to prove to anyone, I'm not trying to impress anyone with my "hacker" skillz.
When I've tried GUI's, I'm not 100% sure what's going on under the covers. Sometimes they try to obfuscate things. While I'm probably not the worlds most advanced user, I know enough to know what I want to do, and how to do it. The CLI let's me do it. The GUI get's in my way.
It's not anything inherent to a visual UI though, it's just that most of the UIs that exist are trying to put their own model on top of git, rather than embracing git's model.
The one exception to this I've found is GitUp (mac only, sadly), and it's excellent. It's whole model is, "what operations can I perform on this graph," which is exactly the model git has. It's great.
I think you've put your finger on the schism of why so many git users prefer a GUI. The built-in porcelain is stupidly inconsistent and confusing. And yet, git's underlying model is so simple and powerful that I think it's worth suffering the bad CLI just to be more fluent and able to utilize git's power fully. The model itself is very easy to grok, it just takes some time to memorize the various random incantations and occasionally look something up, but I don't consider that a big deal for a core tool I use every day.
"C language is so simple and powerful that I think it's worth suffering the bad syntax and memory leak just to be more fluent and be able to utilize the machine's power fully."
Pick the right tool for the right job, man.
Joking aside, think about the ratio of tasks. Most of the git commands I do is deadly simple. There might be once-in-a-year complex tasks that are more suitable to CLI, but for 99% of the tasks I think GUI could have a net gain in total. Although I'm not a GUI user in this particular case, I'd advocate to use whatever most intuitive to you when possible.
Disclaimer: I don't think C syntax is that bad.
1 reply →
It might not feelblike that big of a deal, but certainly there has got to be on any given day far more important things you can use those brain cycles for, yes? Low friction or not it's still friction. Friction that can be removed. Yet so many refuse to do so. There's something wrong with this this-is-how-we've-always-do-it picture.
13 replies →
> The built-in porcelain is stupidly inconsistent and confusing.
That's why I end up using the plumbing commands to do things that porcelain commands don't let me do directly. For example, I'll use git diff along with git apply and recountdiff (from the patchutils package) to stage individual hunks or edit hunks prior to staging.
One could also setup aliases for some of the incantations. I personally have `git uncommit` aliased to the proper command line that I never remember.
1 reply →
The way you confuse git porcelain with git CLI makes it quite clear that you know nothing about either. I'm yet to find a GUI for any VCS that comes close to doing a job as good as any CLI.
1 reply →
SourceTree keeps the same language regular git uses. But I highly agree. JetBrains IDEs add their own lingo out of support for multiple version control plugins I'm sure but its confusing and easy to screw up. SourceTree is the one GUI client I want on Linux...
This is one time when we wish source tree was written in electron!
VSCode is the only Git GUI that you need and it's available on Linux
2 replies →
http://gitup.co/
This looks fantastic, thanks for mentioning it! I've been looking for a GUI that doesn't mesh poorly with [whatever patterns my team uses] / without always pushing other features or a signup.
Thanks for the recommendation. Fantastic looking software that provides a far better visualization of the repo than anything else I have used. Bravo.
I use CLI for almost everything but sometimes it helps to have a visual representation of the repo.
It's a really sweet piece of software, and I'm surprised it's not more popular. I'd be curious to hear how it ends up going for ya'll -- you can message me on twitter at @hazememry if you'd like.
4 replies →
I'd thought a programming language, for manipulating data structures, would work well... but when I had a go at it, it wasn't as easy to use as I thought. It's because the typical usage patterns aren't simple.
A gui with drag-and-drop to rebase a graph also seems like it would work well...
I was in the cli only camp, but I just looked at GitUp and that actually looks really useful!
There are GUIs that are very close to CLI that don't try to reinvent a wheel and instead just map directly to what git does.
The best one, I think, being Magit for Emacs (if you can call that a 'GUI' given you can run it in the terminal).
If you get used to commit things by-line instead of by-file (which is generally highly recommended with git), and also clean up your history/squash things a lot, using git cli gets VERY tedious very fast; I'd rather do it in several keypresses because why not.
Sort of off-topic, but magit isn't really GUI :-) -- though it is very nice, if you're an emacs user. It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)
I think Magit could be classified as a TUI [1].
But that still doesn't help explain its benefits to someone who hasn't tried it. For the crowdfunding campaign that I ran earlier this year I wrote a few articles. For those unfamiliar with Magit I would recommend [2] and the more visual [3].
[1] https://en.wikipedia.org/wiki/Text-based_user_interface [2] https://emacsair.me/2017/09/01/the-magical-git-interface/#st... [3] https://emacsair.me/2017/09/01/magit-walk-through/#start
Well. That depends :) I don't develop in Emacs and use it solely for hosting Magit, in a separate window. So it's kind of a GUI I guess; more so than a CLI anyway.
> It's Achilles' heel is speed, though -- too damn slow. (Last time I tried it, anyway, which was a while ago.)
Don't remember a single of case of it feeling too slow in the last few years, whether on linux/mac... (maybe it just got better over time though)
3 replies →
It seems to be incredibly slow on windows, but fine on linux.
It seems like the sort of ui that needs to be near-instant in order to be usable, the premise being you can tap the various shortcuts to assemble a command very rapidly. But on windows this is an exercise in frustration because each command takes at least a second or two at best to execute and often much longer.
It's a Graphical User Interface.
I think that the distinction that makes a Commnad Line Interface is the REPL.
I consider anything with a non-linear UI that you can see a GUI.
GitExtensions was/is solid too; very little abstraction, it was just built for speed/efficiency. Someone recently told me it runs on Mono too now, but I haven't used it in years and never outside of Windows.
> I'm not 100% sure what's going on under the covers.
This. A thousand times over. I like to see exactly what git is doing and when; I don't want any magic stuff under the covers done for me.
GitHub's GUI is the worst. It has a "sync" button.
As soon as I saw that button I knew I'd have trouble using it.. what will "sync" do? Push my branches? Pull tracking branches? Will merge commits get implicitly created? Or will it just fetch? From what servers? I didn't want to risk having my local master get pushed into production just because GH wants to make things easy for me, so I just quit it and went back to the CLI.
GitHub's Atom editor recently added git operations. I use Atom but haven't had the time to try the git wrapping. Has anyone else used it?
It just pushes the current branch afaik.
9 replies →
CLI and GUI are both user interfaces and magic is in the eye of the beholder: if you know your tools, you can predict what will happen under the hood when you click on a button as much as when you submit a command (it's not magic anymore).
Personally, I use the CLI and often have no idea what I'm doing ;)
Even GUI based SQL tools show you a log of commands used... Git GUI clients don't even show you beforehand or after what the heck just happened... Sad.
It's definitely not true. I'm not sure what kind of gui did you use but both sourcetree and gitextensions show you the command log.
1 reply →
Same here. Regrettably, if you UNDERSTAND git, a GUI won't work for you. If you're interested in understanding it, it won't work for you either.
A GUI works fine if you want to get things done. If you like to know what goes on under the hood, it's just confuse you.
I understand git quite well and use a GUI. I was interested in understanding it while using the git.
It's pretty sweet that GitExtensions displays the exact command executed. Actually, it made learning vastly easier for the people I taught after myself.
Some people do better with GUIs; others the CLI.
I feel this has become a bit of a standard excuse for git. The reason I use a gui isn't because I don't know how git works (while I do forget that too from time to time), but because I can't remember the default behavior and notation of the git cli. I'd be perfectly happy if the cli was actually made to be "low level", but it to a large degree isn't. So if I'm going to have to remember what some abstraction does, it might as well be on a higher level.
One example of this is the table at the bottom of this page: https://git-scm.com/blog/2011/07/11/reset.html
The git CLI is horribly inconsistent.
http://stevelosh.com/blog/2013/04/git-koans/
You might want to try Sourcetree if you haven't already. I felt the same way about Git GUIs for a long time, but Sourcetree actually does a good job of getting out of my way, and has a very nice commit history tree viewer to boot.
Actually I find Sourcetree one of the worst git GUIs out there. There are just so many bugs and kinks and glitches in it that I avoid it if possible.
I do like the Gitx-dev fork by Rowanj [1]. Clean and simple. Unfortunately just for Mac OS though.
[1] https://rowanj.github.io/gitx/
I haven't encountered any of these bugs. But I do use it only rarely, the CLI is where I live most of the time. Good to know about alternatives.
I've found Sourcetree to be way too slow. My team is currently using the GitFlow model, for various reasons, and that involves switching between branches fairly regularly. It also means that any commit to master involves a lot of steps. From the command line, this isn't a big deal because each of those steps takes a half second or so, but Sourcetree multiplies that by an order of magnitude, and the Sourcetree users are nearing a point of mutiny.
Source tree is the slowest software that I ever used. Git extensions is much much faster and I never had any performance problem with it.
I dislike SourceTree precisely because it uses git terminology. Git’s terminology is bad enough, but it completely breaks down for me in a GUI, because I expect that GUI’s conventions there. For example, on the Mac (as in English, I think), a command named “Remove” removes an item from a containing item. “Delete” also destroys the item. SourceTree, however, uses “Remove” for “git rm” because Unix thinks “remove” destroys items.
To make matters worse, what in a Mac GUI would be called “Revert” or “Discard Changes” is called “Discard”, something that, to me, feels more destructive than it is.
End effect? We have “Discard” being less destructive than “Remove”, while, to me, it feels the other way around.
(I may remember this wrong, but if I do, I think that’s a sign of the problem of not following platform conventions in your software)
Not available for Linux, which is a damn shame.
I like fugitive - it feels like cli git without having to leave the editor. GAdd adds the currently file/selected lines, GBlame pulls up git blame information the ability to reblame, GStatus show the status with the ability to jump to/stage/unstage files and so on. Tried Magit for a while but it didn't play nice with evil.
Still hoping for a git repl that just does graph queries/transformations though.
I use both.
Staging, especially partially staging hunks and lines when doing multiple things at once, is way easier in a GUI when you can scroll around for context and easily undo.
For everything else I prefer the command line, because it's faster and I know exactly what is going to happen. I can do what I need to do, no fighting. If I'm just committing everything, I use the CLI. If it's more complicated I use the GUI to stage and commit, and a CLI to rebase/merge/push.
I use sourcetree, but I would like a console feature that shows me what commands its running. Similar to sequel pro's "console" feature shows the raw sql being run.
There's an option in sourcetree, "always show output". This will keep the window that runs the commands open so you can always see what it did and git's output. I always keep this enabled.
the commands themselves are not actually the lowest level, though! (and in fact, are kind of crazily mixed togther; most of the trouble people have w/ git is bad UX for the cli, imo.)
True. Inconsistent and unintuitive options, oddly named commands (and this is coming from someone who enjoys using Unix clones).
How about if someone made a GUI with a console at the bottom that showed the commands being executed along with results?
I like typing and I don't think it slows me down too much, so I pass. But it's a good idea.
This is exactly the same reason I too use CLI. But a word of caution Git Bash on windows has some serious problem(s). I remember, I lost my commit and in reflog it doesn't show up on CLI, however GIT UI showed the same! Not sure what's the issue, but it occurred for me twice.
XCode rolled out a feature that allowed you to do an interactive commit just by click on/off switches. My first use of that feature screwed up the repo by committing the wrong pieces.
No thanks, it’s CLI for me, regardless if the IDE promises git support.
The problem, as I see it, is not with the GUIs, it's with the CLI. Just look at the `reset` command: it does several different things, depending on what switches you give it. How would you represent that in a GUI?
Some git guis log the git commands they execute. Just look at those.
I use either the GUI on Windows or a set of batch files I wrote to automate basic things.
As long as all you're doing is pull, branch, merge and commit, I don't think it matters.