Hacker News new | past | comments | ask | show | jobs | submit login

No, but doing so results in learned helplessness. "Whoopsie, a fucky wucky happened and the GUI I use for git made a big mess. I'm going to delete my repo and clone it again."



Why do you think using a GUI will make it more likely to fuck up your repo than a using the CLI? Most git GUIs are actually better at warning you that you might be about to do something stupid and making the consequences of you actions more visually clear.


I don't think it does. I've observed it many times. The GUIs don't understand git, have shitty defaults, resulting in unnecessary conflicts and histories which are essentially unreadable (Merge branch 'master' of ... x1000). If any error pops up, it is not read (not their fault - NOBODY reads error message boxes, everyone selects the default action within a fraction of a second), if there is a conflict, they usually cannot resolve it with the GUI, or if they do their changes are lost by accident half the time. So in practice when conflicts happen the changes are copied out, the repository deleted and cloned again (because aborting the merge or resetting the branch is unknown / unsupported by the GUI / too difficult or hidden), changes are pasted back in and committed. SUCCESS!

When you use git directly, you at least get all the tools to solve your problems. When you use (most) frontends, you don't. And you learn: If there are errors, just start over - much easier!

This is not the fault of developers, it's shitty tooling + bad tutorials + bad defaults in tooling + unsuitable defaults in git (git's defaults are for the workflow used in the kernel, NOT the workflow most git users use, which is completely different; it's actually amazing that the same tool can support both workflows pretty well, with the right config settings).


In general I agree with you that Git GUI clients aren't great, but there is at least one exception.

On Windows I use TortoiseGit and although I find certain things to require a few more clicks than I would like, it has been able to handle very nearly everything I have ever needed to do with Git. Management of worktrees seems to be the only thing I wish it would add, but once you add a worktree folder using the command line, it is then able to work with it perfectly fine.

It even recently added dark mode!

Every other Git GUI I've tried only seems to cover "pull", "merge" and "push" workflows competently, at best. If you want to do anything more complex like even a slightly interesting rebase, then they seem to be a nightmare. So I completely agree with your assessment there.

I don't really know Git CLI very well and the thought of using it exclusively seems very inefficient and painful. As with any decent GUI program, TortoiseGit exposes available functionality reasonably well and you don't have to resort to reading a large manual to become proficient.

For both Linux and Mac (which I use rarely to work on issues with a cross-platform Electron app), I have yet to find a Git GUI app that I am satisfied with.

When I looked, Fork appears to be pretty good, I should probably at least try the evaluation and if it's okay just pay the seemingly reasonable $50 fee, but it's a pity it doesn't also support Linux.

I know GitKraken works on Linux, but it's one of those clients which is not nearly powerful enough for my needs and it costs $60 a year, I think GitKraken's popularity is largely driven by their eye-candy and that many Git users don't really understand Git beyond the simple workflows.


This is the same debate as whenever some abstraction layer hides details - high-level vs low-level code, automatic vs manual in a car, coffee pods vs brewing machines, hand-tools vs power-tools, ready-made sauces vs make-from-scratch.

As a novice, you don't understand the benefit provided by the tools, so you don't bother learning them. As an expert, you've forgotten the shape and impact of the massive learning curve faced by the novice so you don't understand why they don't bother overcoming it.

I suspect the 80/20 rule applies here - a GUI provides 80% of the value of a source control system, 80% of the time. If occasionally you do have to delete everything and start again, that may actually be a more effective technique than spending a lot of time learning Git beforehand, despite how crazy it looks from the perspective of an expert.


So we've got the best of both worlds here. If you want to go quickly, use a GUI client, but accept you may run into problems down the road. If you want to be able to leverage more power, you'll need to spend a lot more time developing expertise with the tools.

Either way, GitHub's authentication change doesn't seem to be the problem people are making it out to be.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: