Git is a reminder why even the best minds in software development sometimes really should talk to UX/UI people.
It dominated the world despite the UX flaws, which suggests they really aren't that bad.
Especially if you'd have to lose github, thats the real force
If gh migrated to something else, then a lot of ppl would follow
If you prefer you can use mercurial as a git client in the same way.
Most of my git use stays local on my PC, uploading it to github or gitlab or whatever is a secondary concern for me.
If only that wasn’t the case we’d all be using a sensible source control system now instead of one where people repeatedly say things like “if you just learn the underlying model…”
GitHub for many years only had free public repos, not privet, BitBuckets USP was that you could have privet repositories for free.
GitHub "won" because of the social aspect around it and the tooling for open source projects - it never had more generous free levels.
(I like Python! But it's a scripting language, not a systems language. Also the "deployment story" is bananas.)
Yes, you need to follow a tutorial to use it effectively. Designing for beginning users is often detrementantal to advanced users, and I object to that being called "user friendly".
I'm not very vocal about git usually because I'm not an expert I have no big complaints, and I'm not that interested in arguing about it. I think there's a lot of us that are perfectly happy with git; we just make less noise.
At work, we switched from SVN to Mercurial, and from Mercurial to Git. Most people were happy to switch away from SVN, but few enjoyed the change from Mercurial to Git. Personally, it took me much longer to get used to Git than with Mercurial, even though Mercurial was my first DVCS. I now have a slight preference for git, but I am happy with either (just don't bring back SVN!).
Why Git came to dominate and not Mercurial? I am not sure, but I don't think technical reasons explain everything. Its association with Linux probably helped a lot.
> Why Git came to dominate and not Mercurial?
The answer is actually really simple and non-technical: Github. We take these feature rich online code hosting platforms for granted now, but Github was really the leading edge of the wave. It made it easy for people to work together on writing software so it had great takeup and started a Git snowball effect.
I was an early proponent of Mercurial over git. While they are similar, a few “minor” things made a big difference:
Mercurial distinguished between branches and heads, whereas git did not. This added extra complexity.
Git embraced checksums as identifiers while Mercurial provided local revision numbers, this obscured the mental model.
Git is faster to pronounce than either “Mercurial” (which has a tricky vowel in there) or “hg”.
don't make the mistake of comparing "git now" vs "svn then".
It has been described as distributed SVN. I really hated SVN, almost to to point of wanting to go back to CVS, so I didn't want anything that took any inspiration from it. But maybe, in reality, it is not that bad.
Yet, whenever I've worked on git with others, it's been on github (i.e. a centralised model). And I've worked in a decentralised way on svn on several occasions, simply by making my own local repositories and merging changes back to the parent repository when I'm done (which is effectively what git does too when working with remote repositories).
I feel that a lot of what ends up being 'bad' about svn really boils down to the fact that you need some good conventions to be honoured across the project in order to get things done (including using it as part of a decentralised workflow), but humans being humans take shortcuts and mess things up for everyone else. Which really means at the end of the day, the problem isn't the technology per se, but human relationships, manifesting as commit behaviours. Whereas git just imposes its highly opinionated model of doing things on you in order to ward off some of the more destructive human behaviours, which in a sense is good, but at the same time, it means that git can be too rigid, and svn effectively gets a bad rep for being potentially more flexible and scriptable. I've been in many situations where I had to get into an incredibly convoluted manual process to work around git's mental model to get it to work for me, when the equivalent in svn (for better or worse) would have been fairly straightforward.
(Disclaimer: This is just my personal experience from happily using both with no specific preference for one mental model over the other. If anything, I think I may probably prefer svn a bit more now. I'm probably completely wrong about all of it.)
In software we often go for further complexity instead of less. I think because most of us who are the lead developers are often the most intelligent. And we often enjoy these complicated abstract models and they come easy to us. However in satisfying our own intellectual vanity we often don't see how many we leave behind. Which is good for our hourly rates, but less good for creating affordable and simple software.
Anyway one of the main practical advantages git had was decentralized repos meaning you were not dependent on an external server which meant git was often much faster if working with in daily tasks compared to centralized versioning systems
https://stackoverflow.com/questions/804115/when-do-you-use-g...
No it doesn't. It suggests the other features are so damn good that it overcame the horrible UX.
I bet git produced by a no name Linus, in isolation not required by any major project, would have hardly been taken any major uptake.
I think parent's point is that that demographic is positively tiny, and there were plenty of other serviceable offerings around at the time.
The claim stands - git won despite its UX flaws, which does suggest the alternatives, while serviceable, weren't sufficiently fit for purpose.
I think perhaps you're over-estimating the network effect for VCS's -- having multiple version control binaries on your machine is low cost, and aliases can, up to a point, give you a consistent interface to them all.
The highly sophisticated demographic of kernel developers would not have been at the pub insisting that their friends drop svn and use git (exclusively!), anymore than they would have been trying to get any other projects they worked on to adopt bitkeeper previously.
The fact that bitkeeper was required for 'collaboration in Linux development' for so long supports this position.
There were perhaps 5k kernel contributors in 2005, would that be fair? There's perhaps 20k now, I guess.
github alone has 80+ million users.
It's possible, I suppose, that the former is predominantly the cause of the latter, but it seems hugely unlikely.
6 years ago Larry released BitKeeper under an Apache licence. I still don't anyone who's ever actually used that.
The worst systems are the Microsoft ones, but the one with the most complex interface is definitely Git.
I would argue it won because of github. I'm using Git because of that, but still prefer Mercurial in every way.
I doubt that was the intention. Linux just needed a versioning system tailored to its needs, and that's exactly what Git is. Can't blame its creators that other people used it for scenarios it wasn't built for.
This is not one of those times. I agree there's a chance there are better word choices or feedback for some commands, but overall once you 'learn the language' it really is a lean, mean, well designed piece of software.
Folks that complain about the UI/UX don't realize it wasn't designed for less technical folks. It was designed for the folks who needed it.
It's success must at least partially prove that the UI/UX is not 1/10. Any real engineer will tell you, there are times where they wish they could do something better but the requirements and constraints left them making tough decisions, and that doesn't mean they aren't proud of their work.
It's success is also partially due to the fact that it is lean and mean, which allows it to be applicable to nearly all software projects of any flavor. So I don't understand why folks argue it could have been done better. If it was 'better', in my view it wouldn't have been successful. The success was driven by it's succinct design and Linus' take it or leave it attitude.
Technically accurate studio monitors don't sound as pleasing to the ear as good well tuned speakers. But they are exceptional at the job they were designed for. This is like that.
Even the operations which do show will often require more thought to undo than a hypothetical "git undo" would. I know how to use the reflog but I often go out of my way to avoid it because "git branch tmp HEAD; git $POSSIBLE_MISTAKE; git reset ---hard tmp; git branch -D tmp" requires less effort than deciphering the reflog's output.
Undoing a push does require a different set of commands, but my point, to the question @amelius asked, is that you can undo both push and add, and whatever other mistake you’re thinking of, difficult or not.
git reset HEAD~1 Git, coincidentally, does have something equivalent to undo history: the reflog.
(FWIW, I don't consider git complicated and I'm far from a power user)
The idea of a directed graph of file system snapshots is pretty intuitive. Add in branches as pointers to locations in that graph. This is a fantastic model for source control.
However the operations that stage a potential update to the graph of snapshots is prettt confusing. The "index" is a terrible name that is overloaded with so many other non-git meanings, non of which really map to git usage.
That, and all the rest of the names are pretty hard to understand. Particularly reset, whose documentation is inscrutable without translation from git-speak into technical language, or at least a dictionary of what all those words that are used actually mean. And since reset is such a useful tool and has about eleventy different functions, it all becomes impossible to learn from the docs on your own.
The well-documented underlying model used to confuse me a lot - especially for operations like merging, rebasing (squash, reorder, ...), cherry picking, etc. They started to make sense only when I realized that git uses diffs/patches to propagate changes between unrelated commits. While the on-disk format is purely snapshot-based, the tool itself is a hybrid. As far as I can tell, this trips up a lot of others too.
Git has enjoyed overwhelming success, which would seem to empirically indicate that it's done something right in terms of design
Perhaps the obviously wrong UX/UI isn't wrong? Perhaps UX/UI people aren't good at designing interfaces for experts?
It's open source, so why hasn't an alternate interface taken over?
For example, the master/main branch shift. Everything broke when that change was made, but it happened and it wasn't a big deal.
I'm not seeing the difficulty here. It seems that a more reasonable interpretation is that git has the type of interface that is hard to learn, but intuitive once learned.
For CLI, it's easy to create any number of command aliases and scriptlets to have the exact UI you want..
Projects like Firefox and nginx use it, although others like Vim and Python switched to GitHub. I don't know if Facebook is still using Mercurial internally, but for their public stuff they use GitHub.
I think that if GitHub had supported Mercurial like BitBucket or Google Code it would still be a lot more popular, but ah well...