Comment by debaserab2
5 years ago
I don't think a lot of the steps listed in your first example are as painful as you make them about to be. Most of those steps are just as elementary as clicking a button in a GUI to someone with fluency on the CLI. I also doubt the claims that it's that much faster for someone with a lot of experience doing it.
Perhaps you could be faster with the GUI than on the CLI, but learning a GUI doesn't come with zero overhead: you have to understand it's terminology, how it's configuration works, what its icons and symbols mean. Particularly when it comes to VCS management, GUI's like to simplify sometimes complicated or nuanced VCS behavior and you can't really be sure what is being done to your repo until you've pressed the button and done it. Not to mention you are now investing time learning a program that can be abandoned at any time and leave you without the basic knowledge necessary to manage your repo (not saying this would affect you this way, but it could certainly be a reason to not learn it in the first place).
> I don't think a lot of the steps listed in your first example are as painful as you make them about to be. Most of those steps are just as elementary as clicking a button in a GUI to someone with fluency on the CLI. I also doubt the claims that it's that much faster for someone with a lot of experience doing it.
I mean, it's not like you can ever convince me that >10 keystrokes are as fast as 1 click, but regardless, this is easy enough to settle -- just time yourself and let me know how long the steps take you on the CLI.
> Perhaps you could be faster with the GUI than on the CLI
Hence the point!
> but learning a GUI doesn't come with zero overhead:
I don't think anybody claimed this either, so it's fine.
> you have to understand it's terminology, how it's configuration works, what its icons and symbols mean.
It sounds like you haven't used TortoiseGit... at all? How often have you had to look at its manual? How many times have you had to look at the manual of git itself? Honestly, your own reply is warranted here so many times more than it was to me -- "I don't think a lot of the steps are as painful as you make them about to be."
In fact so many of the commands are so obviously self-explanatory (both in text and in icons) that you literally never need to look them up. Stuff that you would never just guess how to do in git itself. Like when you right-click a file in a commit and click "Save revision to...", which also has a floppy next to it. Is it really such a mystery what it does? Is it even remotely comparable to figuring out checkout-index (or whatever the right command is)?
And honestly: it's such a poor attempt at an argument to suggest that the minor ramp-up time of TortoiseGit is somehow not worth the perpetual git pains it saves you from that I don't even know what to say.
> Particularly when it comes to VCS management, GUI's like to simplify sometimes complicated or nuanced VCS behavior and you can't really be sure what is being done to your repo until you've pressed the button and done it.
First, this is such an unnecessary strawman. If you're so worried what some GUI command does, then just use the CLI for it instead.
Second, this is completely irrelevant for read-only operations (like log, Browse Repository, etc.) which were the ones concerned here.
And third... again, it sounds like you're only saying this because you haven't used TortoiseGit, because (shockingly enough, to someone coming from the git CLI) it's not a minefield; in fact it has a number of safeguards. "Commit" creates a commit, "Revert" reverts your changes, "Checkout" checks out a commit, etc... and in fact fails if your tree is dirty, so you don't lose data. Heck, sometimes the git commands it prints end up being more correct than what you'd type on the command line. I know I've learned a fair number of random git features from TortoiseGit.
> Not to mention you are now investing time learning a program that can be abandoned at any time and leave you without the basic knowledge necessary to manage your repo
Again, nobody said you shouldn't learn the CLI. In fact, I'll say it right here: you should definitely learn the CLI, especially for git, before moving to the GUI, or you will be confused (though even then, you'd probably be less confused than you would be if you started with the CLI itself).
> (not saying this would affect you this way, but it could certainly be a reason to not learn it in the first place).
No, it's most definitely not a reason not to learn it.The discussion was never about what you learn in the first place, but what you use. You should learn the command-line regardless. And even regarding usage, it's again a strawman: nobody even suggested you should never use the CLI. The question was "why do people want a graphical git client?" and the answer was "because it makes {tasks} easier", for some tasks. If you find any tasks that don't fall in that category, just use the CLI. It's just a tool after all, not a religion.
> I mean, it's not like you can ever convince me that >10 keystrokes are as fast as 1 click,
I know your reply was to debasarab2 and my upstream comment did say YMMV, but in fact it is a lot faster for me (and likely debasarab2) to type 10 characters than click an icon. My working mode is simply different. We’re not saying you’re wrong, what we’re saying is it’s not universal.
If I Haase to click a button I have to move a hand off the keyboard, shift my gaze, find the mouse pointer, move it, then BT my hand back to the keyboard.
Whereas on a command line I always know where my keystrokes go, I never have to move my hands or look away from the screen, and I have >40 years of typing at computers wired into my basal ganglia. (This is despite the fact that the first computer I used, a CADR lisp machine, had a mouse and bitmap display). GUI interfaces are simply much slower for me, except in very unusual applications. I am not claiming it to be universal but it is clear the affordances of the command line are significantly lower-friction for people accustomed to them.
My hands are on the keyboard most of the time too, I'm not a particularly slow typer, and there's no way I could write a proper git checkout-index command at the speed of just a click or two.
But again: I will believe you if you measure it and report back. So far the only person who's measured anything has been me, and I have to wonder why others are so averse to it.
Yeah, if you consider my arguments to be strawmen, then using a VCS GUI for the narrow use case of tracking down diffs might save you a solid few minutes. That just feels like a drop in the bucket compared to the overall time spent developing. YMMV I guess, depending on what organization/codebase you are working on.