I nearly spat out my drink. Git is many things but those aren't the first two words that would leap into my head.
What is complex is the hundred features and commands it provides on top of that model.
I strongly disagree.
Let's list just basic git concepts that you're likely to encounter fairly early on: the working tree, staged commits, branches, remotes, stashes, detached heads, tags, submodules, merge conflicts, squashed commits, fast-forwards, rebasing, cherry-picking.
Some of these you could choose to ignore - rebasing and submodules - but on the whole you need at least a cursory understanding of everything on that list to get by without a git angel to get you out of trouble. I still have a person I phone when anything out of the ordinary happens and I've taught git to other people!
I'm also genuinely surprised that people use GUI for git. For merge I understand, but for all other tasks cmdline is easier and faster.
Which is exactly why people want better clients than the official git cli client.
For me, I just Right click -> TortoiseGit -> Show Log -> scroll -> Right-click -> Browse Repository.
How long does it take you? For me it takes < 10 seconds (I just timed myself).
I understand that YMMV -- de gustibus non disputandum est -- but I have ever understood the appeal of GUI tools especially for something like git. I do use magit, but even then I do most manipulation with the command line interface
This misses the point of the problem -- the point is you don't know precisely what string to grep for.
> or git log > file and look at it in an editor. no need to change the tools just for this unusual action.
I mean, nobody said this 1 reason should be enough to make you switch tools? I was just giving an example.
And no, it's not "unusual" just because you say so to try to dismiss the problem. I know I use Browse Repository as well as the GUI logs pretty frequently, and they're godsends compared to your solution.
And lastly: this is what your solution actually looks like:
1. Dump the entire log output into a temporary file
2. Open that temp file in your editor
3. Look through the commit messages/dates/names
4. Realize that's not quite enough to narrow down your search to a single commit (maybe you want to see the diffs or file paths or something else?)
5. Try to figure out which flags you should to pass to git log to dump all the info you need
6. Call git log again, hopefully now it dumps all the info you need
7. Open the temp file again in your editor
8. Scroll through your file containing diffs/names/whatever extra info you dumped
9. Type 'git checkout COMMIT -- file/path' once you find something
10. (Hopefully,) before you press Enter, realize you're about to trash your current copy of the file, which had some other changes
11a. Run git stash, and now suddenly messing up your staging area that you'd carefully staged changes in, and also messing up the file metadata (e.g. Make will now rebuild everything...), OR
11b. Figure out how to run git checkout-index -a -f --prefix=/destination/path/ so that you check the file out into a different directory.
12. Once you have a copy of that file, look through it, maybe examine/pull out the code you wanted (or whatever)
13. Remove the temporary file you checked out.
14. Remove the temporary file in your editor.
15. git stash pop.
And somehow you always do all the above without making a mistake, otherwise have fun reverting or recovering lost data.
With a GUI log TortoiseGit's log, you literally:
1. Click on a commit with the date you're interested in
2. Select Browse Repository
3. Double-click each file you want to examine to see the diff
4. If it's not the file you want, press Escape and click again.
Not only is the number of steps smaller, each one is also significantly faster, and less risky too. No need to mess with a single temporary file, fire up your editor manually, or risk losing anything.
Anyway, again: this was just 1 example meant to get the idea across, hopefully with the aid of your imagination to extrapolate to other scenarios. But if you're going to trash this all with "this never comes up" I don't really have the energy or interest to keep bringing up examples or try to convince anyone; you should just keep using the CLI.
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 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 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.
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.
If you have a dirty wd, stash.
But, to be honest, I almost never perform that action, and when I do I use the web browser.
You remember the hash of your June commit 3 years ago??
> But, to be honest, I almost never perform that action, and when I do I use the web browser.
Web browser... for a local repo? Or do you mean you don't have a solution if your repo isn't on GitHub or you don't have an internet connection handy?
(You should also time yourself on your web interface by the way.)
...which is what the git log above is there for.
> Web browser... for a local repo? Or do you mean you don't have a solution if your repo isn't on GitHub or you don't have an internet connection handy?
Yeah, local repo. You know, git is not GitHub. :)
> (You should also time yourself on your web interface by the way.)
Just paste the hash commit in the HEAD selector or even in the URL.
So a graphical interface then? I'm sure you can see why using a GUI for other functions is just as useful.
For something like git, the slightly more visual representation is a benefit to many, too.
I'm not here to knock CLIs, there are a set of tradeoffs to be made, and CLIs win in many cases (flexibility, scriptability, being able to copy snippets you frequently use, etc). The above does tend to hold true, however.
Its output is so rich and complex that it's impossible to make it legible outside of a real GUI, with graphics and colors.
'for a new person, it's almost impossible to get anything done with a table saw'
And I've never used one, but I'm sure it takes some learning, skill, and practice to get good cuts the way you need them, e.g. bang on 45deg all the way across for a 'mitred' corner joint. And it certainly needs learning, care, and attention to operate safely.
I don't mean it to be an insensitive analogy - accidents involving table saws are obviously horrendously worse than those involving git.
I work in a very large monorepo, so it's not like I'm working in a git tree that isn't complicated.