I'm waking up to a lot of Discourse on here about Git so of course here's my take:

I am increasingly uninterested in saying that tools are "good" or "bad”. It's all just so contextual.

But I can't think of a tool that I've used as long (over 10 years I think?) and as frequently (daily), that frustrates me this much and that I make bad mistakes with this regularly (monthly at least). Something about Git just DOES NOT fit my brain. (This is not an invitation to explain git to me!!)

[1/3]

I've observed that this seems to be true for a lot of people — there's a large group for whom Git just never "takes”, and always feels uncomfortable.

This seems to align along what I might call a specialist/generalist spectrum. People who are more “pure" software developers — studied classic algorithms and data structures, create new and novel tools — tend to take to Git. People, like me, who float around a bunch of disciplines, where coding is part of but not THE job tend to struggle.

[2/3]

My flippant snarky line I use sometimes is "I'm too stupid for Git”. This isn't really true: I don't think I'm stupid, and I don't think other people who struggle with Git are either.

But it captures something — Git feels aimed at a very high skill level. It's a "black diamond" tool, "experts only" terrain. It was created by experts, for experts, and while there's been recent work to try to make Git more accessible, that fundamental nature hasn't really changed.

[3/3]

@jacob Ignoring the git part for a moment I try very very hard to not label tools or software as good/bad. Someone made a choice and that’s why the team is currently using it and it may not be the one I would have made but as long as it’s working (or the time and lost opportunity costs to change are too high) I make myself live with it and try to make it better.

That said I really need an excuse to try some alternate source control systems!

@r343l yeah same. I lapse when I'm frustrated and am not as good at this as I'd like, but when I'm thinking clearly I nearly always can see why something is the way it is.

@jacob Git for me is in the class of tools that has what I call “a lot of sharp edges” (there are many tools I use regularly that are in this class sadly). Within the “doesn’t get it” side of git users, there’s a variety of subgroups of users who’ve learned to mostly avoid some part of the sharp edges. But the sharp edges are still there. It’s like git is a system that depends on mostly #4 and #5 of the hierarchy of controls. https://www.cdc.gov/niosh/topics/hierarchy/default.html

@jacob (Also I must note that I frequently end up writing software or tools that have sharp edges because only so much time and gotta get it done and it sucks so much knowing I will cut someone else … and probably myself in 2 months when I’ve forgotten I left myself a sharp edge.)

@r343l oh neat I hadn't seen the Hierarchy of Controls before, useful model, thanks for sharing that!

@jacob It is so useful! I mostly know about it because it’s used in manufacturing processes (which I have some awareness of from jobs) but also a somewhat common metaphor used by transportation policy wonks / activists. I don’t think I’ve consciously applied it to software before that reply but realized “sharp edges are things we strive to remove or separate in physical systems. why don’t we do that for software?!”

@r343l it instantly reminded me of a risk mitigation framework I use in security all the time: https://medium.com/starting-up-security/the-five-factors-used-to-secure-systems-7f58be0f447f (I use a personal version of this that I've heavily modified, renamed some things, added a sixth level, but the never wrote about publicly)

@jacob @r343l these are both great resources. Nothing here is really *new* to me (I love importing ideas from industrial safety and I think I have heard these talked about indirectly before) but these are great frameworks to organize ideas about safety.

@jacob Something I find fascinating is that this is not an uncommon feeling about git, and yet it is by far the most popular tool of its type. Most tools that are as difficult to use as git is would be thrown away, but git somehow is powerful enough or entrenched enough or something to avoid that, and that’s sort of amazing.

@jacob I find this especially interesting because I started with Hg but moved to Git in part because I found it easier to work with, and I wouldn’t expect us to be that dissimilar on paper. Feels like there could be some fascinating HCI research on exactly how things like that happen, but it’s harder to study people in the workplace than college students so I think it’d be hard not to over-focus on new learners, too.

@acdha yeah, I mean, the "expert/amateur" thing is a _vast_ oversimplification, but it's the closest I've come to being able to articulate a difference between many of the people for whom git "clicks" and those for whom it doesn’t.

@jacob thanks for sharing this! I am curious if you could unpack the specific types of mistakes you make, or how the frustration manifests practically. I am coming from the opposite end of the spectrum here: I have criticisms of git because I find it simplistic and limiting, rather than over-complex, but I ~never make mistakes with it. Which means I am often called upon to fix issues, and I can, but then I struggle to articulate the solution in a way that the person I am helping can understand.

@jacob omg. this is exceedingly salient to some work I’m going to be doing the next six months. I’ve never formally learned security stuff for computers. so probably should start my remedial training.

@r343l very cool! If you want more resources or wanna chat about it some time, hit me up. The five factors stuff is usually the _second_ thing I teach about risk, it's fairly beginner-friendly but does make some assumptions about terminology, risk analysis, etc.

@jacob Yeah I probably should do some searching. I know I’ve picked up a lot by necessity (eg that post links to the ruby on rails csrf preventing docs which I’ve read so many times and related stuff) but I lack conscious knowledge of the “theory” side of security stuff.

@flooey I definitely don't know. I've heard it explained as an example of "worse is better" but I don't buy it. I think that's dismissive and reductionist. It's probably more of the case that Git has a whole bunch of great features that are good enough to make it worth using even for people who find it frustrating.

@jacob @flooey as someone who has frequently described git this way this makes me think I should change my rhetoric, because to my mind the whole deal of the “worse is better” essay is an enumeration of great features that UNIX had which Lisp smugly ignored, which had greater practical impact than the hypothetically-better fundamentals of Symbolics’ architecture. Lisp/bzr had stuff I wanted one day, unix/git had stuff that I (and everyone else) actually needed immediately

@glyph I lose work regularly and consistently. Monthly, probably. Fucking up merges or rebases, deleting the wrong branch or similar, trying to remove something from a commit and deleting the file instead, etc etc. It's "my fault" in the "human error" sense — it's always me doing the wrong thing vs an actual bug. Sometimes I'm able to get things back by fighting with the reflog but usually it's faster to just cry for a minute and then re-write the thing.

@r343l I learned security “backwards" that way, starting with specific security engineering things (adding XSS/CSRF protection to Django was my first exposure) and eventually working towards theory. It totally works! But that said there are a couple of frameworks for thinking about risk, and some terminology, that I like to teach to engineers because it helps them bridge the gap and speak the same language as security folks.

@jacob If there’s specific things you suggest reading, feel free to suggest! That post seems at least to have some useful links to dig through as well.

@glyph @jacob oh I can tell you a specific point of confusion I have. When I'm doing something where I want to go back in time… like a rebase or amending a few commits back… etc. I'm never quite sure if I should put the hash of the fucked up commit or its parent

@maco @jacob haha okay this one is relatable. The only reason I don’t make this mistake is because I have learned to just start cherry-picking once I get into this situation so I can just treat things like diffs and ignore commit relationships

@glyph if you want, I'll try to remember to take a screenshot or whatever the next time I inevitably fuck it. It might be today!

@jacob thanks, yeah, this is very consistent with my experience. All of the real “what the fuck has happened here” scenarios I’ve dealt with combined a merge and a rebase, and my biggest complaint with git’s UX as a whole is verb conflation (“rm” operating on both the tree and the index is a big one)

@jacob It’s interesting that you characterize it as “fighting” with the reflog though. I am realizing that I might have more comfort/fluency with it because many years ago I spent weeks deliberately *playing* with the reflog, learning how to explore history, etc. I suspect many git-dislikers’ experience of reflog has a visceralally negative valence, because the only reason one touches it in the course of normal operation is when the deletion of your work is a very salient Damoclean blade

@glyph @flooey that's funny, I never knew the original genesis of that phrase. In my mind it's more linked to things like vhs/betamax and what we might today call "enshitification" (eugh)

@jacob @flooey it is a classic. Worth reading in its entirely, although I should strongly say I do not agree with all of its conclusions: https://dreamsongs.com/WIB.html

@jacob @flooey particularly salient to this discussion are the sections “integration is god” and “non-lisp environments are catching up”

@maco @glyph hah yeah same. I also consistently confuse `checkout`, `branch`, and `reset` (and now `restore`), and have to look up the syntax for renaming or deleting branches every time.

@maco @glyph oh and `clone`. Right this minute I can't tell you what the difference between `checkout` and `clone` is. `clone` is how I get a repo from github onto my machine, right? I think that's right but only feel about 80% about it without looking it up.

@jacob I only use the GitHub client. I think I used CLI git prior to GitHub’s app, but basically as incantations. I imagine I’m *capable* of learning to use CLI git, but it feels like having to develop expertise in particle physics in order to use a light switch; I just want to turn the lights on and off, maybe use a dimmer.

@waldoj @jacob one time I really messed something up and it couldn't be undone through the app. I went straight to colleague helping me with CLI git incantation rebase head rebase sparkle fluff and a specific commit and it totally made no sense in a way I was able to relatively quickly understand

@danhon @jacob Sometimes I've made mistakes in Git where somebody will be like "oh you just need to reflog the head and then cut a new branch to remerge with HEAD as a part of a rebase," and before they've finished their explanation I've just submitted a huge commit titled “fixing broken stuff.”

oh no not your gitflow

@waldoj @danhon I have strongly considered adding "reflog" to my list of muted words on here, because to me "reflog" is basically that "did you just tell me to go fuck myself?" meme

@glyph @maco I once broke something with cherry-pick so badly that I needed to delete the entire .git directory, re-clone from upstream, and manually merge my changes back in. No clue what I did but I don't use cherry-pick any more lol.

@jacob @glyph I get it. Git has some of the worst UX of any tech in regular use I've ever encountered, and that includes Nortel phone switches whose sold interface was a TTY where one could enter numeric codes as commands and get other codes as responses :)

But there is another way. Problem is it requires discipline, and care. I'm NOT suggesting "Oh just shape up and stop whining" as there's plenty to gripe about, but I am suggesting that if you're losing work that regularly, you might consider changing the way you work just a bit to minimize that.

I avoid complicated rebases like the plague. I think the idea of "Clean commit history" has caused more pointless pain and lost work than anybody properly accounts for.

I work on my branch, regularly merge from main, and anyone who tells me that seeing a few merge commits is going to ruin their day is welcome to take a long walk off a short peer. Keeping things simple means more to me than anyone's precious opinion :)

@feoh @jacob “I think the idea of "Clean commit history" has caused more pointless pain and lost work than anybody properly accounts for.”

Standing in a room by myself, clapping and cheering in response to this

@feoh @jacob there’s no shortage of superficial flaws that do a lot of damage (verb-confusion is a pointless UX own-goal) but the desire for rebasing comes from the atrocious presentation of what SHOULD be the main selling point of the whole system, merge commits

@glyph see this is the difference I was trying to articulate. You are the type of person who wants to play with tools and understand how they work (and are usually capable of figuring anything out!). I admire the hell out of that but it very much isn’t me. I use tools to accomplish some task and want to think about how they work as little as possible. The perfect tool in my book is a microwave: “press button receive potato”

@jacob In this specific case that classification applies, but I would push back against it as a binaristic generality. everybody has stuff that they enjoy playing with. I’m sure you’ve played with the web a bunch, and you probably wouldn’t characterize what you were doing as playing with HTML to learn HTML; you were trying to build. And I wasn’t really playing with reflog for its own sake either, I was interested in building community workflows at a time we were transitioning from svn to git.

@jacob But clearly there are lots of immediately visible, fun, interesting things that one can do with the web. A much larger audience is going to be excited about it. The main thing one can do with reflog Is “not lose your work”. Which is pretty low salience until you’re, you know, about to lose your work. But you are a security person, and I am pretty sure you’ve been excitedly engaged in exploring problem spaces playfully there which would most programmers bored enough to cry blood :-)

@glyph oh yeah for sure it’s an oversimplification. I think it gets at something true (or that feels true) about different approaches to software development. But it’s hard to articulate in a way that’s not overly simplistic.

@glyph @feoh @jacob I suspect it’s in no small part driven by the default linear presentation of git history. I’m not sure it’s really plausible to actually have a decent UI representation of merge commits in the terminal, though?

@jacob @glyph this made me realize 1) I have no idea what a reflog is though I’ve heard of it befor me 2) the degree to which I’ve come to rely on visual studio code’s autosave+keeping-deleted-files-around-til-close+ctrl-z-undoes-what-git-just-fucked-up is actually absurd.

I treat git as an information destroying application that occasionally syncs to the CI server, and I stopped noticing because the goddamn intuitive Microsoft product lets me stay helpless.

@alpha @feoh @jacob I can think of a dozen ways to do this but none of them are interesting until someone actually makes one happen for real :-)

@glyph In practice, this thread at least made me (metaphorically) get off my butt and actually look up git log documentation to find --first-parent, which solves most of my issues w/merge representation in git log.

@glyph But also, this is also pretty much me - I very rarely make mistakes with it and am usually the git guru on my teams, and basically am able to make git do what I want since I do have a pretty good mental model of what I can do with the abstractions. Though that being said, I don’t think my criticisms of git are that it’s simplistic or limiting, but more around the UX and mental model being divergent. Also that people often actually have a fairly reasonable model of the commit graph (modulo usually thinking of commits as diffs, but eh, that’s generally fine) but are lacking a good mental model of refs and HEAD and the index.

@alpha personally I find that it elides too much and then the commands to “unfold” a “subcommit” are too much faffing around, so I just do things the hard way by looking at graph views and tracing things out. But it *almost* does what I want

@glyph I often want to find a commit to fixup, which is never in a commit from a merge.

@alpha eh, “simplistic” was perhaps a poor choice of words. I agree with pretty much everything you say here. The “simplistic” nature has to do with its exposure of the things that keep the implementation simple (“refs” paths, sha hashes, string-based subcommand dispatch) as major parts of the UI; not that they’re simple, really, more that they are not thoughtfully abstracted

@glyph I think also for the most part, except for @b0rk, no one’s really covering those other essentials in git tutorials, often focusing on esoterica that I think aren’t relevant at all for actually using git.