Git is a tool for creating and navigating a directed acyclic graph of revisions. It’s fine to chuckle and make fun about how esoteric that sounds, but at the same time I expect people that work on my team to rise to the challenge of proving that they occasionally attended data structures and algorithms class.
I understand not taking a day to learn git, I really do. It’s hard to find the time to learn everything that comes your way at work, and you’re not exposed to the practical challenges that augment documentation as part of learning if you try to crush it out all at once. But, if someone can’t learn git, I don’t know what to do with them. We’re not cranking out websites in an agile, typewriter-pool style open-office, sweatshop. I need people that can learn things at least as complicated as git, because they’re gonna have to keep up.
And those can (read:should) have a visual representation, yes? Why are we still typing archaic/cryptic commands - read: wasting brain cycles that could be better spent - for what are ultimately manipulation of something best represented visually?
It's time to move on. I'm sure someone will fax you when the time comes. Hopefully, you can keep up :)
- Gitk
- Tower for OS X
- Github
Besides, some people enjoy using CLI tools the obvious reason that they're simple to use and can be used programmatically with minimal overhead.
I mean, you're just describing the act of programming in general here.
Just because something is hard it doesn’t mean it’s worth doing.
When I interview people for software engineering roles in 2019 who haven't bother to learn Git or struggle to understand it's use-case, basics and relatively simple to use interface I can quite easily use this to make some important assumptions about the candidate. The most important being that maybe software engineering isn't the right career choice for that person, at least not yet.
Is there room for improvement? Sure, but let's make sure where ever we go, it's to a better place, not a worse one.
branch checkout add commit pull push
Reading and understanding the documentation for those six core commands isn't a big investment, and it will pay off if you're doing software or documentation development.
Not to get off topic, but it's your #1 job as team leader to put your people in the best position to succeed. Pounding you fist on desk and shouting "keep up" doesn't cut it.
The question here isn't what is or isn't learnable. The question is, why so much tension and friction (i.e., using the CL) when a visual representation is actually the far better representation of the model / data?
Keep up? Why are we tossing rocks in their toolbox?
This is not a defense of the status quo. It's an observation about working within the status quo. If I could choose for everything else to remain equal but git get easier, of course I'd take it. I'd choose for a lot of things to be better, not just software.
My observation is that of all the things a developer might encounter for the first time on our project and be asked to learn, git isn't a standout. This is what I meant by keeping up; there's a lot to learn.
We do what we can to reduce the load, spread it out, and I refine the crash course for new developers every time someone goes through it. But at the end of the day, we have jobs because we can pick this stuff up and get to work with it. Even if git is less than the platonic ideal of version control.
It mystifies me. Git isn't hard, nor complicated. "Checkout" has a few too many meanings, and thats the singular gripe I have with it.
I know many devs that only use git through their editor or some other git UI and don't know more than commit, pull and clone in the terminal.
Inevitably they always need help when something gets screwed up, or they jump through endless loops to somehow get the desired result through the UI
To me, Git via the command line, constitutes industry "jargon". It's used - wrongly - to help exclude certain people within the broader culture. Git + CL === elitist.
It's also anti-dog food'ing. But perhaps this helps explain why so many UIs and UXs are so subpar? That is, the less you use something (i.e., a proper UI) the less you learn about them?
p.s. What about SourceTree?
Personally I prefer the command line, but I imagine your coworkers will be a lot more receptive to using version control tools the way they're used to.
If you're concerned about command line complexity, you can try out gitless: https://gitless.com
It's a simplified command line interface to git, designed by looking at how users actually use git.
Git isn't a corded drill in this analogy, it's an electric motor: the potential foundation of many different tools for different problems. There's nothing wrong with it, it's just that it would make more sense to use it as the basis of a more complete, ergonomic tool, rather than just sticking a drill bit into the spinning part.
/usr/bin/git is like curl: a command line tool for precise manipulation of an underlying data model/protocol. It's complex, but it works great - if you want to interact with the underlying data model/protocol on its terms. Many people want something that automates a more complex workflow to help them accomplish a higher-level task. For HTTP, we have browsers; for git, we don't have much yet.
You should do a lot of learning on using a table saw before you touch one. Using git wrong won't kill you, using a table saw wrong will.
The text editor analogy falls short in that version control has to be used by the entire team whereas a text editor only has to work for an individual developer. So, I can see the argument that the standard version control tool should be a little more intuitive. I think one challenge though is that, in my experience, it's not even the command line so much as some basic concepts around vcs that people struggle with, so "more intuitive tool" is a hard challenge I think.
The regular people lose two days of work trying to rebase their merge commits to appease those folks.
Rebase should never have become part of the day to day git toolbox. If it didn't exist nobody would ever see a linear history, and so would never think to care about it.
Thank the maker for github's "squash merge" and "rebase and merge" buttons, which handle all that crap for you. If you're not using a tool that does that for you I'm sad for you.
Git is the C++ of version control. Of course it’s powerful. Of course it can do everything. And of course it’s a huge frustrating footgun with error messages that rival any c++ template compiler error.
The problem is that we have made it a de facto standard so it’s hard to replace. Even if a much better VCS emerged tomorrow, it doesn’t help if there isn’t support in large issue trackers, CI/CD systems, IDEs and so on.
I have great hopes that pijul will be the better git. But again, it’s the tooling and ecosystem that matters, not the qualities of the vcs itself.
My takeaway from that essay was that in the real world, you will never see a contractor using a Hole Hawg, or anything like it, and hackers have a uniquely fucked-up attitude to human factors. Hackers will excuse the most tragic of user interfaces, with some kind of macho "rite of passage" bullshit. Yes, "macho":
"Now I view them all with such contempt that I do not even consider them to be real drills--merely scaled-up toys designed to exploit the self-delusional tendencies of soft-handed homeowners who want to believe that they have purchased an actual tool."
See? It's all about self-inflicting pain, because if you can't tolerate the pain of a crappy user interface, you're not a real hacker [1]. I see it in the defense of git's crappy user interface ("the reason you can't remember the 50 semi-orthogonal cryptic commands is because you haven't grokked its perfect model of directed acyclic graph theory"). I also see it in the perpetual defense of Emacs' crappy user interface (infuriating, because it is a powerful piece of software). Hell, I even see it in the defense of the command line interface itself (and associated scorn of GUIs) - many of its design decisions have been baked in since 1969, yet to listen to many apologists its perfection is such that it might as well have been carried down the slopes of Mount Sinai by Moses himself.
This is a major cultural problem with our community. Maybe, if we actually could bring ourselves to admit that our interfaces suck, we might start to make a little progress towards fixing them. Because right now, "tolerance for unreasonable bullshit" is a major filter for who gets to do programming.
"...when I got ready to use the Hole Hawg my heart actually began to pound with atavistic terror. But I never blamed the Hole Hawg; I blamed myself."
Yes. Blame yourself. Blame yourself for using a stupid tool with a bad user interface.
[0] http://www.team.net/mjb/hawg.html [1] https://xkcd.com/378/
Plus there's an intrinsic elitism in it being hard to use.
Tradesmen use all kinds of tools like that, which is why trade schools and apprenticeships are a thing. I bet there are weekly articles on how to get the most out of your Fluke in the trade press, we just don't read them.
Don't get me wrong, version control is necessary. Obviously. But if a plumber, a word-worker or some other artisan used a tool that required a weekly "It's okay, you'll catch on eventually" article, we would have never got out of the Dark Ages.
It's time for an intervention. It's time to take seriously the friction and frustrations it creates. Yes, it has redeeming qualities. But it's time to stop looking past those and do something about them (other than another article such as this one).