4 ms·
I've resigned myself to accepting git because I have to use it. But JFC, I've hated it from the first time I tried it. We now have a large selection of tools t
by crispyambulance 4y ago
I've resigned myself to accepting git because I have to use it. But JFC, I've hated it from the first time I tried it.
We now have a large selection of tools that allow you to visualize what's going on (I use git-kraken), as well as google for help on doing something that isn't in muscle memory.
But, really, SO MUCH pain and suffering could have been resolved by refactoring the damn commands to something more coherent and consistent. Git people sometimes call this "porcelain"-- which I guess is an apt name because it makes one think of a toilet (but an improvement to a hole in the ground).
- jacquesm 4y agoSeconded. Git, like Linux is used everywhere, you can't avoid them. And even though I use it externally locally I use subversion, whose commands make a lot more sense to me. But Linus has something going for him: he knows how to establish critical mass for his projects, and how to create viable ecosystems.
- airtonix 4y ago[dead]
- fisherjeff 4y agoThis is maybe the most cogent version of my exact feelings on git I’ve ever read. In theory, I have no issues with git! In practice, the UX is often very very bad.
- kinkrtyavimoodh 4y agoi am no apologetic for the messy git UI. But i also know that any competent software engineer can be given a sufficient understanding / mental model of the basic git way of doing things in 1-2 hours, after which they can Google for the exact syntax of the commands they need (if they are doing complicated things). i feel that if they are unwilling to invest even that much time, then they are going to waste an eternity on endless tools and GUIs. it's like tar or rsync or ffmpeg. Yes, it's hard to keep track of all the command line flags etc. but thanks to the internet we don't need to. it's far more useful to understand the underlying concepts.
- hungryforcodes 4y agoAnd how do you KNOW this? My experiences-- and many other's experiences have suggested otherwise. Also it's foolish to suggest that one of the 21st century's most complex repository management software is just like tar, or rsync. What planet are you from?
- crispyambulance 4y agoGit is intrinsically a graph model. It's well-suited for very rich and effective visual representations. If the cli "matched up" with a visual way of thinking, for many of us, the cli would become second nature. But it just doesn't match up. It's fugly and needlessly hard to remember and become fluent in at least for us "incompetent" engineers who already have too much to work on.
- KronisLV 4y ago> We now have a large selection of tools that allow you to visualize what's going on (I use git-kraken), as well as google for help on doing something that isn't in muscle memory. Git Kraken is excellent, though Git has a page on various GUIs, many of which are free with no restrictions: https://git-scm.com/downloads/guis https://git-scm.com/downloads/guis Personally, on Windows I like SourceTree: https://www.sourcetreeapp.com/ https://www.sourcetreeapp.com/ Some that have worked with SVN back in the day like TortoiseGit: https://tortoisegit.org/ https://tortoisegit.org/ On *nix Git Cola seems to do the job for me: https://git-cola.github.io/ https://git-cola.github.io/ Then again, the most complex workflow I've worked with was Git Flow and I didn't need anything more advanced than that. Come to think of it, I don't really do rebases often either and mostly just take advantage of squashing commits through GitLab/Gitea and such, when needed. But hey, that's also valid, using Git in a way where you get version control but mostly keep the technical details out of your way (though Git LFS and certain cases with particular line endings being needed does make you drop down occasionally).