I did maintain Git for a few months, and the thing that made me ask Junio if he wanted to be the maintainer is that very-hard-to-describe notion of "good taste". I don't really have a better description for it: programming is about solving technical problems, but how you solve them, and how you think about them is important too, and it's one of those things you start to recognize over time: certain people have that "good taste" thing and pick the "right" solution.
I don't want to claim that programming is an art, because it really is mostly just about "good engineering". I'm a big believer in Thomas Edison's "one percent inspiration and ninety-nine percent perspiration" mantra: it's almost all about the little details and the everyday grunt-work. But there is that occasional "inspiration" part, that "good taste" thing that is about more than just solving some problem - solving it cleanly and nicely and yes, even beautifully.
And Junio had that "good taste".
And every time Git comes up, I try to remember to really make it very very clear: I may have started and designed the core ideas in Git, but I often get too much credit for that part. It's been 15+ years, and I was really only involved with Git in that first year. Junio has been an exemplary maintainer, and he's the one who has made Git what it is today.
Btw, this whole "good taste" thing and finding people who have it, and trusting them - that's very much not just about Git. It's very much the history of Linux too. Unlike Git, Linux is obviously a project that I still do actively maintain, but very much like Git, it's also a project with lots of other people involved, and I think one of the big successes of Linux is having literally hundreds of maintainers around, all with that hard-to-define "good taste", and all people who maintain parts of the kernel.
This also reminds me there are different dimensions to taste.
A developer can have both excellent taste and skill in code and lack one or both in its user interface. For instance, I'd personally say git seems to be amazingly successful and robust but that the UX could be much more consistent without sacrificing any power.
I fully expect there are other dimensions to this too for other overlapping domains in software engineering. Something like E.g:
- testing - does the test code work? (skill), is it making the most of opportunities for coverage and self-documentation (taste? Or a different kind of skill?)
- API design - can it do what's required? (skill), is it a sensible ABI too? (skill), can others understand it? (taste), is boilerplate minimal? (taste)
- documentation - is it correct and complete (skill) and understandable? (taste)
- code review - can you spot bugs and inconsistencies? (skill), are you giving feedback that allows incremental improvements without overwhelming? (taste)
I fully believe both skill and taste can be learned in all these areas but different thought processes will help in each.
Sometimes a good abstraction should leak. I hated Subversion and Perforce because both seemed like mystery boxes; I could use them but I never felt like I understood them. With git I've never had that feeling, if anything it's the opposite. Git is easier to understand than it is to use; the data model is simple enough to figure out in a few minutes, but learning the nuances of the various commands and flags takes a lot longer.
Leaky abstraction is not git's problem. Git's problem is shit like "checkout -b". Why does git-checkout have a flag to do what git-branch is for? Convenience of course, but this kind of shortcut makes git harder to learn initially.
For the rest, I would agree. Git is at its core technically "simple". But the CLI UX is quite, let's call it, involved.
I think there are two primary reasons for that: Git is a very interactive tool. That just doesn't go well with a UI which is fundamentally a line printer.
OTOH Git is very powerful. Most GUIs (or TUIs) can't "handle" this well, imho.
Git is "feature overkill". On the command line this doesn't matter much as you never see all features and options at once—besides of course that nobody can remember all those switches. ;-)
But when creating GUIs, which are better in the interactivity dimension, this becomes a real hurdle. Basically you have only the options to hide things and dumb-down your tool or end up with a overloaded and therefore quite complex GUI. Really hard to strike a balance.
The best I've seen so far regarding Git GUIs was Sublime Merge. It also hides much things at first sight but manages to not lock away Git's power by doing so. A lot of features are contextual. Also you have an "intelligent" command palette at your disposal. This matches nicely with the interactivity of Git! Also the GUI is strongly inspired by the look & feel of Git's command line output.
Sublime Merge feels for those reasons in large parts like if the command line tool would be "projected" into a GUI (which is convenient as the CLI output is already quite optimized to see everything relevant quickly), but given the GUI one does not need to remember the awkward command line flags.
Git on the command line should be more like that I guess. At least a kind of build-in REPL would be good as Git is interactive not "batchy".
I know there is a "git-repl", but it's not really what I imagine. It's not really context sensitive or interactive.
"Magit" looks good from far away, or at least heading in the right direction, but it only runs under EMACS.
If there would be something like Sublime Merge for the command line (and maybe even available OOTB) this could solve quite some of Git's usability problems I think.
I agree, git made more sense to me after 6 months than svn did in the 5 years prior. The whole conflation of directories, branches and tags made svn an irredeemable monstrosity.
I’m really happy with source control at Google (perforce on a huge monorepo?). My experience with GIT has always been trying to find dummy guides on how to do simple things.
I have a lot of respect for both Linus Torvalds and Junio Hamano. I think git has been very important, Linux even moreso. But why didn’t darcs or hg win instead? I will never know.
The answer for why Git beat Mercurial in overall usage more or less boils down to GitHub being very successful. That isn't to say that Git wasn't already in a good position prior to that, but GitHub made it very easy to get into Git in a way that hadn't really existed before. (Anyone who used CVS or SVN on SourceForge knows what I mean.)
At that point, it's just network effect. GitHub made using Git easy enough that people were willing to accept a clunky interface. It's not like people expected great interfaces from CLI programming tools in 2008, anyway. People are still using Mercurial, in any case.
As for Darcs, I used it. It's cool. I'm not convinced it's that much easier to understand than Git, and it has well-known performance issues.
Git was already very hype before github arrived. Every LUG and CS club was having people evangelize git seemingly every week before there was even a whisper of github. I think it got this hype from the association with Linus and Linux.
I think so. Mercurial had a lot of people using it, lots of features .. yet something made git blossom way higher very rapidly. Maybe python perf made a difference ..
The interesting thing to keep in mind is that there is a subjective aspect to taste. Personally, I do not care for Linus's taste in programming or system design, but I absolutely respect his immense skill within his domain.
