Why don't people use git properly?
22 points by srxl
22 points by srxl
Realistically, the only way we improve the general quality of git usage in the developer population is by significantly improving the quality of education in the software world.
I'd like to propose an alternative solution, that's more realistic than improving the quality of education in the whole world: make git easier to use.
My unscientific theory is that git's (lack of) ease of use isn't actually the main problem. Sure, it's not the easiest to learn, and a lot of command names are unintuitive. But whenever I've helped people get to a working level with git (I'm far from an expert myself, but proficient enough that I have seen a lot of the pains in the article among colleagues throughout the years), I've found that what people miss is a mental model for what git sets out to do.
Once people internalize what git is trying to track, and how commits relate, most of the wall seems to crumble. The oddly named commands are just a google away, and insignificant in the big picture. The important thing is to get rid of a fantasy model of what git wants to do (as an example, I've found that a lot of people think that git tracks changes).
In 2012, I joined a company that was using Git, while I was previously on Subversion. In 2013, a guy joined who had worked with OpenStack and Gerrit- we quickly adopted what I felt was a highly productive culture, including making an effort of having a clean change history, with single-purpose commits.
I felt the change history was great- in that gig we had to refer to the history quite often, and I think it was pretty worthwhile. Also, in my opinion, thinking in atomic changes, made us better engineers- it makes you think more about what you're doing.
I quit that company in 2019 and... I still work in that way, but personally, it's never been a priority for me to nudge my colleagues into improving. I've worked with others who knew how to make changes "well", but... I've corrected some flagarant problems, but really, it just hasn't felt like a priority. I rarely need a good change history nowadays, and the organizations I work for have problems several orders of magnitude more concerning.
PRs and squash merge are horrible, but they are low effort and reasonably effective. And also, sometimes it's just about working in smaller chunks and not obsessing if occasionally you spit out big chunks that could be smaller.
We still reminisce about how productive and nice Gerrit felt, but I think there are bigger fish to fry first...
About this part:
A startling number of actually existing software professionals, by contrast, are completely at sea when it comes to command lines. [...] the bulk of software development work still happens on Windows machines, and while it's less common than it was, it's still not unusual for developers to not really have access to a command line at all: [...]
That's my experience as well, after starting a job at a Windows-only company as a Linux user: the whole shell experience under Windows feels painful (the terminal emulator itself is limited and cranky, Windows CMD shell is way too limited and complicated, Powershell feels too overengineered for daily use). I have settled on MSYS2 and KDE Konsole for now, but a) that's quite a bespoke setup, b) this software has bugs as well (which are probably not discovered/fixed because it's a niche user base), and c) integration between MSYS2 and the rest of Windows is difficult.
Do you have recommendations how to get a "good" shell experience under Windows (without spending days fine-tuning it)?
Btw. on my colleagues screens I basically never see a shell window. To me this seems like one of the main limitations of Windows as a dev platform: a whole world of automation is absolutely invisible to Windows devs. They don't even know what they miss out on.
tbh im kinda in a rush, gotta catch a flight, but your vocabulary is so radically different than the Windows way... the Windows console is not a "terminal emulator", it is based on emulating 80's tech, not 70's tech lol. The "shell" there is the gui explorer, not the command line processor. And that whole world of automation is done through (actually pretty comprehensive) object-oriented APIs and programming languages, not piping text through little utilities in a bizarre janky shell language. (tho lol jscript and vbscript janky their own ways)
to be fair, the unix way has basically won and microsoft has moved to it; powershell was them trying to compromise and now the windows terminal actually is a terminal emulator, and they ship WSL etc. But it was never that Windows just didn't support the automation and such, they just did it very differently.
and tbh i wrote my own unix-style shell for windows (and linux, made it cross platform), using the newer pseudoconsole api so i get what you're coming at, just i wanna defend the Windows way too to some extent.
Fair point; I'm used to the Linux way of automation and might be myself blind to the Windows way.
Um what? I spent several years using windows for the usual web development people do. WSL 1 and 2 were basically like having a linux box there for the most part. Windows Terminal (now) is really good. For windows scripting/usage, powershell is very underrated. I had a bunch of scripts that I used daily and then ported to fish once I switched to an apple silicon mac.
Any tool on any platform you decide to adopt is going to take a bit of time to learn and git gud.
WSL 2 + Windows Terminal, as echoed by another comment, is what I've found to "just work" w/o any tinkering. Being a Linux instead of a Windows experience means more dev tools tend to work well in it.
I tried using Windows 11 as my main development OS for about 8-9 months the past year. While having WSL is infinitely better than Windows without WSL, I did not find it to just work. I used Ubuntu (reluctantly, as it's the most supported), and would pretty regularly run into weird errors, and had WSL get stuck in crash-loops out of nowhere. Sometimes I could only solve those by rebooting all of Windowfs. Because I wrote code in Helix within Ubuntu, WSL crashing would sometimes take my work with it. I tried researching this problem, and tinkered with WSL VM settings, but nothing ever made it completely stop crashing.
Also, Windows terminal looks fine at first, but can be quite janky. It is the only terminal emulator application I have used that would crash when I moved a tab between different windows (specifically, when I moved a tab from one window to be the left-most tab in another window, the latter window would often crash).
Ultimately, for those reasons among others, I ended up switching back to Linux.
I'm sure you did experience that, and I'm not sure why, but it seems decidedly outside the norm from what I've seen. WSL1 was a whole different story, but WSL2 has been quite stable in my own use and for everyone I've known who used it heavily. My last job was very windows heavy, and I lived in WSL2 & debian as a daily driver under win 10 and 11 from the moment it was available on enterprise builds. I can't recall having a single crash of the core stuff, and only a handful of flaky moments in the terminal app, over many years.
I still default to bare metal linux for almost all of my own machines, but wouldn't hesitate to pick up more WSL2 again if there were a reason to.
I'm also not sure why! I would have preferred not to run into any of that. I did encounter some people on the internet who also had the weird WSL errors that I did, but admittedly it didn't seem common. Maybe my Windows installation was cursed.
But I can't lie that being back on Fedora feels like a breath of fresh air. Even though it also broke on me almost immediately after an update, and required rolling back the kernel to fix (maybe it's me that is cursed). So I think my personal experiment with Windows as the OS I use for anything but games that don't run well with Proton is concluded for the foreseeable future, haha.
I tried using WSL2 for a while on my i9-13900 laptop.
It was pretty annoying that the default 16 GB : 16 GB RAM split wasn't enough for what I wanted to do in Linux. I could just barely make things work by changing the split to 22 GB for Linux and 10 GB for Windows, which made Windows run pretty janky.
Access to USB devices e.g. flashing code to microcontrollers/SBCs via USB-UART adaptors was .. well, I just always did it from Windows. And setting up ssh into the Linux environment from my other machines was a pain, but can be done.
The final straw was that taskset is not honoured in WSL, making reproducible benchmarking of A/B code changes impossible. Not only do you not want to get migrations between cores in the middle of a run (let alone to/from E cores), there is also the fact that two of the P cores (4 threads) run at 5.4 GHz while all the others run at only 5.2 GHz, so if you can't control which P core you get that's a 4% run to run variation right there.
I wiped Windows and installed Ubuntu natively and haven't looked back. I lost about one hour of light-use battery life (6 hours down to 5 hours) but that's fine. I never need more than 2-3 anyway.
That's why I wrote Yori - trying to get Unix like capabilities in a native Win32 shell. Popping up though, I wanted a Win32 shell because the rest of my developer environment was Win32 - people advocating WSL are probably using a very different environment.
For backstory, I joined the Windows development team in 2005 and was a bit surprised that they used a heavily customized command line environment. It wasn't possible to be part of that team without using a command line. In hindsight this makes sense, because it was a team whose origins were the late 80s/early 90s, where IDEs didn't really exist and definitely couldn't scale to the task. Of course, everything about it was Windows - initially I tried Cygwin and even manually porting Unix tools but the lack of integration was just too painful.
Not sure I'd agree that CMD is complicated - it's just a bespoke evolution of an assembly-written command.com that didn't have any consistent grammar, and I've found it really hard to retrofit a consistent grammar to it without creating a radical departure.
I have used several different version control systems in my career. CVS (briefly), VSS, ClearCase, Subversion, Perforce (briefly), Git, Mercurial, recently Jujutsu. Many of them had flaws or could only handle certain kinds of workflows, but the single WORST in terms of basic usability that I have ever tried was Git.
Until recently, I used Git almost exclusively because the entire software world converted to Git and I had little choice. But I believe that a lot of the usability problems stem from the design of Git. Why don't people use Git properly? Because it's incredibly difficult to use at all, much less use properly.
Recently I have been using Jujutsu. It has a new working model (editable commits, which I find interesting, although I'm not sure I like it better) but more importantly it is a viable version control system that can use Git as a back-end so I can use something other than Git while still interoperating with the rest of the world. (For a while Mercurial came close to doing that, but the compatibility was always fragile.)
Because it's incredibly difficult to use at all, much less use properly.
How so? What do you find difficult about it?
My answer is it's just too damn complicated. It's almost worse than tar which has options from uppercase lowercase a to uppercase z with double options. Yeah it's common but it's got a terrible command line interface.
What this is to say, then, is that if you don't have a good grasp of how git works using the command line alone, you're almost certainly going to find yourself having real trouble when it comes to doing anything but the most basic tasks using the GUI version.
The author clearly hasn't tried magit.vc, which with its discoverability made me more confident with git than the CLI interface (well, they say it is a Git Porcelain).
I think the thing about not learning their tools generally applies to many developer tools, say debuggers, editors/IDEs, etc.
Not learning git CLI well is indeed a problem not helped by git CLI not being a thing with enough structure to be suitable to learn well (git internal model is not sufficient to express some things well, but I guess this is a complaint requiring learning at least the bare minimum by rote memorisation to have enough fluency to know that the things are indeed missing)…
People who aren't comfortable with command line aren't going to be using emacs...
What is your point? I am just saying that Magit's discoverability helped me learn the advanced features of Git that I would've never tried otherwise.
I am not comfortable with git’s command line, but I am a pretty advanced user of magit, and of other command line tools in general. Git is probably in the top 3 worst CLIs I’ve come across in 40 years of computing.
You simply don't have to ask "why don't people use Jujutsu properly?"
There were no user studies or interviews that went into the original Git porcelain UX, nor was there much engagement with the existing space. Tools which come out of one person's autodidactic vision tend to be very uneven — they tend to have great parts, and also parts that make newbie mistakes. The staging area is one such mistake. (Jujutsu shows that it provides no additional power over using a stack of two commits.)
There were no user studies or interviews that went into the original Git porcelain UX […] Tools which come out of one person's autodidactic vision tend to be very uneven
I'm saying this as a happy Jujutsu user, but wasn't Jujutsu also one person's vision at one point?
My understanding is JJ started as Martin's hobby project. I'm sure he was influenced by existing software, and maybe Google or Mercurial or even Git had commissioned user studies for their own software at some point. But I'd be very surprised if he had initially designed JJ around the results of a user study.
There was a lot of user research that went into many of the workflows around which jj is built.
Thanks for the details!
It sounded funny to my ears that "Linus had no such large-scale experience", seeing as Linux was one of the largest (the largest?) open source projects at the time. Maybe the other factor is he had a very different experience as the lead developer of Linux; he built a BitKeeper replacement that fit his own workflow to a tee, at the partial expense of the contributors' workflows. Whereas Martin's experiences at Google would have been much more focused on contributors' pain.
I'm also curious to what degree Git's UI was indeed one person's vision. My impression (after falling down a historical rabbit hole) is that Linus's original Git was just a low-level content tracker, whereas today's Git is an aggregation of desire paths on top of that:
The answer is that [the porcelain commands] sort of slowly eked their way in over several years, mostly as shell scripts that evolved to scratch a series of itches.
Another way of looking at it: Jujutsu, when using the Git backend, is in some ways a brand new porcelain with a unified vision—but that vision came from someone with broad awareness of users and their pain points. In contrast, Git's porcelain evolved organically, also from the trenches but without a bird's eye view. And what makes sense locally can get you stuck in a local maximum, even if Linus (and later Junio) had done a perfect job curating it.
I was on the source control team at Facebook, where we regularly did user interviews across the entire spectrum of experience levels. jj borrows extensively from much of that
Did Martin work at Facebook too? Or are you saying that Google undoubtedly did something similar?
It sounded funny to my ears that "Linus had no such large-scale experience"
Ah yeah, in this context, I mean "large-scale experience deploying a source control system to tens of thousands of users with a variety of backgrounds and experience levels". Many people who use source control are not developers, and you really get to see these systems' UX break down when they have to use it as part of their job. (This is a problem with the tools, not with the people!) That's just not an advantage Linus or the people who worked on Git early had.
Did Martin work at Facebook too? Or are you saying that Google undoubtedly did something similar?
Martin never worked at Facebook, but Google and us at Facebook collaborated together on Mercurial for a few years. Martin and I were on the Mercurial steering committee together for a while, and I have the utmost respect for him.
I mean.. the hard parts of git are still hard on jj (there is no version control tool on earth that can free you from writing commit messages), but the easy parts are much harder (like not screwing up your history).
Shipping with (something like) revset-aliases."immutable_heads()" = "all()" would be a start, but jj is pretty much the polar opposite of what I'd like to see in a "modern git".
Hmm seen in this light probably a lot of the people doing it wrong see git as some kind of hazing ritual or shibboleth.
The rest of the article talks about git’s role in plumbing and minimizes the idea that it’s a useful part of a personal workflow:
There are very few ways in which you, as a junior on an established project can make a mistake that makes you go "oh shit: hard reset, hard reset!".
I do this semi regularly to, for example make sure my local branch is the same as remote. It’s easy for me because I understand git and what it can do for me.
I used to have a colleague (sadly out of touch) who used to tell people who wanted to learn to code to learn git before learning anything else because it is the undo function for your code. I wonder if the problem is that people who don’t really use VCS don’t use it because they never develop a workflow around it, and hand roll their own workarounds.
I suspect that the undo function and personal workflow perspective is the key for people to learn.
They panic at a merge conflict. They produce 12,000 line commits with Claude Code and a terrible commit message.
I object to being lumped together here!