I think the worst failure mode I've ever seen is one team that maintained a "git repository" for a collection of analysis scripts that was simply a directory on a shared drive. It was technically speaking initiated as a git repository, but practically speaking it wasn't used as one: rather, the directory contained zipped copies of the code timestamped with when they were modified. There were very few commits to be seen, and I honestly hesitated to try and branch from them in any meaningful way. Of course there was no command line interface or anything to be had, and the git GUI software they had available was muddled enough that it confused me. In this situation, yes, *technically* they were using git, but in any real sense this clearly wasn't the case.
To be fair, I think those devs have a good idea on how a content-addressable-filesystem-cum-blockchain should work. The primary use-case, Linux kernel development, has very particular needs such as being distributed, allowing complex merge strategies, and being aggressively transparent. That the rest of the world then adopted this particular (D)VCS was mostly an accident.
Back in the before times when git was first new, I was an avid supporter of svk (a perl hack that bolted on distributed qualities to svn). Very useful to have complete server state locally especially for merging. svk worked, but had a lot of foibles, being the hack that it was. When I finally pulled the trigger and migrated repos over to git, even those early versions, reduced the complexity of my setup dramatically. Haven’t looked back since. The porcelain of git has improved dramatically over the years (even if I still use git checkout -b). But it is still very much an expert tool and most users don’t engage deeply with it. Which is exactly what the blog post recognizes and laments because the supposed experts aren’t.
What irks me about it is that they can’t even agree on simple things like should it have one command e.g. checkout for multiple things, or should it be separated to multiple (switch, restore, checkout).
They can’t agree are they making a tool for idiots or developers so they go from one end (reset) to another(restore).
So users end up with an entangled mess of a overlapping yet not fully covering commands.
Then comes the so-called “expert” saying:
git is the shape it is for very good reasons, and we wouldn’t, for example, try and dumb down a milling machine or a lathe because they’re hard to use
Yet they don’t ask themself why do new users think it has too steep learning curve, or an entry barrier.
So calling it “expert” tool is mockery by my standard. (If not obvious I agree with Mira Welner, git is critically overdue for good command clean-up before there can be talk about experts)
Maybe if newcomers had clear image of how git is supposed to work with clean easily explainable set of commands, larger percentage would stay on the wagon, just saying.
To be fair, I think those devs have a good idea on how a content-addressable-filesystem-cum-blockchain should work. The primary use-case, Linux kernel development, has very particular needs such as being distributed, allowing complex merge strategies, and being aggressively transparent. That the rest of the world then adopted this particular (D)VCS was mostly an accident.
Back in the before times when git was first new, I was an avid supporter of svk (a perl hack that bolted on distributed qualities to svn). Very useful to have complete server state locally especially for merging. svk worked, but had a lot of foibles, being the hack that it was. When I finally pulled the trigger and migrated repos over to git, even those early versions, reduced the complexity of my setup dramatically. Haven’t looked back since. The porcelain of git has improved dramatically over the years (even if I still use
git checkout -b). But it is still very much an expert tool and most users don’t engage deeply with it. Which is exactly what the blog post recognizes and laments because the supposed experts aren’t.What irks me about it is that they can’t even agree on simple things like should it have one command e.g. checkout for multiple things, or should it be separated to multiple (switch, restore, checkout).
They can’t agree are they making a tool for idiots or developers so they go from one end (reset) to another(restore).
So users end up with an entangled mess of a overlapping yet not fully covering commands.
Then comes the so-called “expert” saying:
Yet they don’t ask themself why do new users think it has too steep learning curve, or an entry barrier.
So calling it “expert” tool is mockery by my standard. (If not obvious I agree with Mira Welner, git is critically overdue for good command clean-up before there can be talk about experts)
Maybe if newcomers had clear image of how git is supposed to work with clean easily explainable set of commands, larger percentage would stay on the wagon, just saying.
I felt they were pretty clear here. checkout is overloaded. switch and restore are the new, simpler ways. I switched (ha) myself and it was painless.
I also get the reluctance to deprecate or delete checkout because the whole world uses it