Comment by echelon
5 years ago
I'm really curious - why do people want a graphical git client? The command line exposes everything, and the model is simple and intuitive.
I work in a very large monorepo, so it's not like I'm working in a git tree that isn't complicated.
> the model is simple and intuitive
I nearly spat out my drink. Git is many things but those aren't the first two words that would leap into my head.
Git model is simple.
What is complex is the hundred features and commands it provides on top of that model.
> Git model is simple.
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!
1 reply →
Git is a great example of worse is better philosophy.
Thats exactly wHat GUIs are good for. Make infrequenlty used features and options accessible.
1 reply →
The model is relatively simple, but the UI is a disaster.
Which is exactly why people want better clients than the official git cli client.
I find that it has too many magic commands built-in so no-one really gets to learn the under-side of what's actually occuring so when it eventually breaks like everything does, you have no idea what you did wrong. An example would be how the git pull command is basically a bunch of different git fetch and merge commands.
1 reply →
Say you want to find a commit that occurred around June three years ago, and look at what the repo looked like after that commit -- without checking out any files. How do you currently do it?
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).
Not against GUI or anything but just curious about doing it from CLI: git log | grep 'June 2017' (and remember the first 5 characters of hash) And then `got checkout <hash>`
I think you missed the part that said "without checking out any files"?
2 replies →
git log | grep -- find the hash of the one I want. or git log > file and look at it in an editor. no need to change the tools just for this unusual action.
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
> git log | grep -- find the hash of the one I want.
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.
5 replies →
Probably just GitHub (the browser UI). If you want to do it offline or from the command line, I understand why you might hesitate want to check out files, but stashing in git is extremely easy.
git log, copy paste hash, git checkout
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.
> git log, copy paste hash, git checkout
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.)
1 reply →
> "when I do I use the web browser"
So a graphical interface then? I'm sure you can see why using a GUI for other functions is just as useful.
Try doing a merge with IntelliJ's 3-way merge UI. It's flippin' fantastic compared to roaming through the files and removing sections between >>>> and <<<<.
Command-line git allows you to specify a mergetool, many of which are capable of three way merges.
The point was convenience. I don't have to leave the IDE.
1 reply →
Many people are visual. It's a lot easier to see changes, compare diffs, and generally follow the development branches through a GUI instead of through a command line.
I think the main advantage of GUIs in general is a contextual, curated explorability that is often lacking in CLI tools. The GUI is stateful, allows the user to click on things and prod it, and hopefully shows the most frequently used features for that context. This allows even complete newbies to be productive almost immediately.
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.
Git is famous for being unintuitive?
Infamous, and a more accurate description might be that discussions about git are well-known for quickly descending into discussions about whether or not it's intuitive and whether or not that matters since you use it every day you'll soon get it and no longer care that much how intuitive it is anyway.
Just give thanks that you did not have to work with the likes of CVS and such.
One of the advantages is you can easily explore what changes were made and merge conflicts through the tool.
I like to drag and drop commits into an order I want when doing an interactive rebase.
That's easy with the TUI
Dragging and dropping? Or do I have to rearrange the lines using a text editor?
1 reply →
I wonder the opposite thing: why do people try to use git in a terminal?
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 git command line
You could say that about any tool, of course you have to spend some time to understand how to use it safely and effectively.
'for a new person, it's almost impossible to get anything done with a table saw'
do people say, "a table saw is simple and intuitive"?
2 replies →
I think most folks like a graphical merge tool, such as opendiff, or at least that's what I've been able to glean.
I work on a lot of repositories, having a GUI makes it really easy to change context and getting up-to-speed quickly.
As someone else mentioned here, the graphical merge tool in IDEA is extremely powerful. Plus keyboard shortcuts to all the main Git actions. It's overall more efficient. However I always use Git IDEA + Git CLI side by side.