Git seems to have it all. It's hard to imagine what anyone else can compete with, how they can differentiate. There's such a variety of ways to work & rework git repos, so much sheer capability available to use as you will that it's hard to imagine what more one could want.
Indeed it feels like most competitors are competing by offering less. This is our way! This is easier! But you're not going to win the alpha geeks over with that path. Better needs to be bigger, needs to enable more, and we're just not seeing those offerings materialize; it's unclear how you would be better or bigger.
Having the core abstractions that work & are flexible enables bountiful innovation & improvements. Git not only started with sufficiently malleable core ideas, but it's had endless features, optimization, and tuning baked in over the years. It's almost too much to comprehend. Shout out to Taylor Blau writing on the Github Blog: the man has been doing an amazing job covering what's happening in with the Highlights From Git series, since September 2018. It's really given me a sense of how much work keeps being poured into git, has given me a view of how incredibly expansive the git ecosystem is. https://github.blog/2018-09-10-highlights-from-git-2-19/https://github.blog/tag/git/
It is ridiculous how many nice features git has accumulated through the years, but their discoverability is... not excellent -- partially because of how many options we now have. It's a vicious circle.
Git has biggest moat of all software, and it is stifling innovation.
On one side it's good because everyone is using the same tool and we don't have to learn many different intricacies of other tools.
But on the other side, there's probably a better way of doing things that could dramatically simplify everything.
It was designed so long ago with such different computing and memory constraints, and the way we use repos today is very different - think monorepos.
There are so many projects trying to bandaid solutions to its scaling issues, and so many projects are using monorepos today which are not well supported.
I genuinely believe re-writing a VCS is actually a very simple task.
If you look at the core use cases, or the commands people use, they are very few.
Coming from the days of CVS and SVN, git was a freaking miracle in terms of performance, so I have to just put things into perspective here when the topmost issue of git is performance. It's just a testament how huge are the codebases we're dealing with (Windows over there, but also Android, and surely countless others), the staggering amount of code we're wrangling around these days and the level of collaboration is incredible and I'm quite sure we would not have been able to do that (or at least not that nimbly and with such confidence) were it not for tools like git (and hg). There's a sense of scale regarding that growth across multiple dimensions that just puts me in awe.
git may have become successful, but that doesn't mean it's right. I'd argue that most developers still don't really understand git. I know seasoned, senior developers who struggle when git gets into an unfamiliar state, or who are completely mystified as to how it actually works. And don't forget that git spent years improving its initially horrific UI to make it easier and more palatable to people who aren't kernel developers.
If you compare git to rival tools such as Mercurial and Fossil or even Darcs, it's pretty evident that git didn't really win on technical merit, user friendliness or indeed hardly any other metric. It was fast, and it had the dubious advantage of being better than a lot of crappy alternatives at the time, and of being the product of a famous developer. But if technical merit was how we chose software, we might all be using Mercurial today. It's quite possible we'd be better off, too.
git's punting of "certain of the hard theoretical problems" lead to major shortcomings in its design. For example, git does not track branching histories. Once you merge your changes back into a branch and delete the origin branch, the path that your commits took are lost. Another example: Since git's data model works entirely on repository snapshots (there are no "patches" or logical operations, only snapshots), it doesn't know about file renames. Some commands, like log and diff, do understand how to detect renames (but not out of the box!), but it's fundamentally a fuzzy-matching operation that can only work perfectly if you separate your rename commits from modification commits, which is rarely feasible.
Don't get me wrong, git has overall been a force for good, but I think it's a pretty terrible example in this particular case. In fact, I'm not sure I can think of many cases where the "worse is better" philosophy was ultimately a good idea. In every instance that comes to mind (MySQL, MongoDB, PHP), the fast-and-loose attitude ultimately came back to hurt everyone, and years were spent paying for those mistakes, plugging one hole at a time.
The original decision by the Go team to build package management into the language ("go get") was made without really understanding the problem, and this decision has been haunting us pretty much since day one, with developers having to chase unofficial package management tools of the week in order to get their work done. I really want it to be done right, even if takes a bit longer. It's a problem worth solving well.
It's interesting how all the cool things seem to come from Microsoft these days.
I still think we need something better than Git, though.
It brought some very cool ideas and the inner workings are reasonably understandable, but the UI is atrociously complicated. And yes, dealing with large files is a very sore point.
I'd love to see a second attempt at a distributed version control system.
But I applaud MS's initiative. Git's got a lot of traction and mind share already and they'd probably be heavily criticized if they tried to invent its own thing, even if it was open sourced. Will take a long time to overcome its embrace, extend and extinguish history.
Personally, I enjoy that we rally around a common set of tools, as an industry. And Git is probably the best choice in its category. But that may have to do as much with adoption and network effect as it has with inherent quality. It's an advanced tool, but many folks struggle with the less common tasks, while many others struggle with even fairly basic things like a rebase. In an ideal world, if I imagine it, there'd be a tool like Git that lives at a different plane of usability. And I am unsure that a monoculture would be very encouraging in ever getting us there.
I disagree that Git's biggest flaw is its lack of scalability. Cases where git needs to scale tend to be isolated to companies that have the manpower to build a finely-tuned replacement (see: MS, Google).
Git's flaws are primarily in usability/UX. But I think for its purpose, functionality is far more important than a perfect UX. I'm perfectly happy knowing I might have to Google how to do something in Git as long as I can feel confident that Git will have the power to do whatever it is I'm trying to do. A competitor would need to do what git does as well as git does it, with a UX that is not just marginally better but categorically better, to unseat git. (Marginally better isn't strong enough to overcome incumbent use cases)
And for the record: I think git-lfs issues are primarily usability issues, and tech improvements. The tech enhancements will be solved if there's enough desire, and as I mentioned the usability problems are more annoyances than actual problems.
I feel like not having a git for human consumption is a huge missed opportunity, and I do hope something like that will arrive soon-ish. People in software development seem to not realize at all just how abysmally awful git's UX really is. Explaining git to a non-developer person who just wants me to assist with a python issue always feels a lot like explaing thermodynamics to someone who just wants to boil a kettle of water; yeah, sure, not interested, I've just sent you the file by email, please have a look.
I feel like making collaboration less painful has been the greatest innovation driver in the last few decades, and has paid off absolutely enormously. Imagine where a git/Github for other disciplines could take us. Given software developers build such tools, and given software developers overwhelmingly know how neat git really is, it's actually kinda strange that there's still such a dearth of good solutions in this space.
1) A tool for managing collaborative work through a beautiful distributed graph theory tree model[1]...
2) ...with a very, very difficult to use UI. Unfortunately:
3) A good, intuitive UI for manipulating the underlying model without ignoring edge cases or removing functionality is extremely difficult, and indeed, nobody has done it yet.
So you periodically see these articles pop up decrying the UI, but nobody ever makes a great UI that wraps the underlying tools. This article talks positively about gitless, and it's a great tool, but it gets a good UX only be hiding/disabling large chunks of functionality. And like most tools...
4) Git suffers heavily from the 80/20 rule[2].
I'd say 95% of the time, I'm using maybe 5% of git's features. But the other 5% of the time, I'm using another 1% of git's features but it's always a different 1%. I might go weeks without needing to cherry pick a commit, but when I need to, I really need to...and gitless doesn't support it (or most other "complicated" features). But the reason git beat out the competition isn't git's excellent UI or large marketing budget, it's that those features actually provide significant value.
And so we get a slow drip of articles like this. "Man, it would be nice if there was a better git UI that had all its features!" It would indeed.
Having worked with CVS, Perforce, subversion, bzr, mercurial, and git, in distributed teams, as a sole developer and in large local teams for over 20 years, I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems.
Git is a tool, and it's certainly not going to be a 'flip a switch and everything is better'. It does require that you define how you're going to use it in your particular context, but the only tradeoff I can see with git is learning it. It's interface and naming is an absolute horror show of usability, but its no worse that something like regular expressions or vim/emacs. But once it's in place, you have change management calculus, and everything else was algebra at best.
I understand the frustration of people who are used to having the benefits of open history in addition to open source. And who don't want to step back 10 years and learn dead end technologies, and who aren't used to being confronted with ivory towerism or gatekeeperism.
Otoh, I also understand why a maintainer would want to keep their codebases close to their chest, when they've achieved expert level finesse in a project/codebase, and the noob hordes with their ill-conceived ideas demand responses to their pull requests because they spent their free time writing some crap, and demand you spend your free time educating them on why their patch is a tub full of fail.
It's really hard to overstate how much of a sea change git was.
It's very rare that a new piece of software just completely supplants existing solutions as widely and quickly as git did in the version control space.
Git is ... alright, but it doesn't deserve quite as much praise as it gets. I have well over a decade of experience using source control at a fairly high level, and I have experience with a wide variety of source control systems. Git is currently more or less the best thing that's out there in a lot of ways, but it still has a whole shit-ton of shortcomings.
Even when you use git according to the finest shade grown, hand picked, organic best practices available you are still going to routinely run into situations where dealing with git is just a straight up pain in the ass for no good reason. Every source control system has its weaknesses but in some ways git's are even more annoying because so much of the rest of it is engineered so well. It's like opening up the trunk on a maserati and finding a compartment that's lined with splintery unfinished recycled pallet wood and held together by chewing gum, it makes you wonder why it's there and why having some piece that is such a comparatively low quality continues to be tolerated year after year.
Again, overall I think git is pretty great, but the persistent lack of effort toward improving git's core weaknesses is incredibly frustrating.
Like Linux, git is taking a while to "mature" from a user's perspective. It's ludicrously powerful -- it's as much as file system as a distributed VCS -- and its 1,001 options need to be distilled for the masses into the handful and a half of essentials.
It's worth contemplating that Linus doesn't hang around defending git. He put it out there -- bless him -- and let it take on its own life. And its destiny is up to us.
git doesn't need to be taken out of the command line. That's where its true power lies, as with all *nix tools. The fact that github can do so much with it is because of this feature, not because they are changing it. That's a powerful thing, and a testament to Linus' design of git.
I bet Linus never envisioned github when building git. And that something so revolutionary -- and I do think github is revolutionary, albeit for a niche of geeks -- should come out of such a development is testament of git's design.
Sure it's a hard package to master -- I haven't -- but whatever you want, and a lot more, is there if you need it. And no-one yet, to my knowledge, has complained that git killed their project.
Why is git so successful? It has good internals and has had those good internals for years and years, which covered up for its many flaws. Add on to that: network effect due to linux, github, and gitlab all using git.
Git is great, compared to most of the alternatives. But is it perfect? Of course not. Is it hugely flawed in parts? Of course it is. It has a UX designed by freaking engineers FFS, it's surprising it's as usable as it is.
The observation that git forces you to learn how its guts work so that when you inevitably end up in some scary situation with the potential of losing or screwing up revision history you know enough to work your way out of it is not a strong argument. It's similar to the lament about how older cars were so much easier to work on and that made them better. Better if you want to work on cars, perhaps, but a vehicle that requires constant maintenance is not superior to today's cars that can be run for 100k miles with minimal engine work and a single set of spark plugs, and are also safer, more efficient, and cleaner to boot. The same thing goes for VCSes, if you're regularly, or ever, getting into hairy revision history problems that's a sign of a weakness in your VCS and/or workflow.
The only major problem I see with Git is that it's just a pain if you're working in a gigantic monorepo.
Outside of this, I think it's achieved it's ultimate form and tradeoffs for what it was originally intended to do - and the majority of projects fall under that category, meaning that while Git can be improved, but it doesn't need to 'change' architecturally or philosophically to accommodate other things.
Separate version control software can be designed for solving a specific problem - but I don't think Git should need to evolve beyond the problems it's designed to take on.
Git is typical of a tool built by engineers. It has good primitives but a clunky overall design and horrible UI. It does not naturally encourage the most effective modes of use. Hell, even the "best practices" of the git community are highly questionable (just rewrite history for aesthetic reasons, what could go wrong?).
Git is highly tuned to the use case of serving linux kernel development. Many other folks have figured out decent ways to use it effectively as well but don't mistake that for Git being an unquestionably good tool or for it being "easy". Sure, the core workflow is pretty straightforward, but the fact that the easy stuff is easy is not a ringing endorsement of a tool. Good tools make hard stuff easier and easy stuff trivial.
Make no mistake, I think there are lots of awesome parts of git, the most important being its distributed nature. It's trivial to setup a repository because everything is a repository. That's pretty potent, and git has some reasonably well engineered components inside of it which make it fast for many common use cases, which is fantastic. But a big part of why git has been so successful lately has been because it hasn't had a lot of competition. Much of the competition is either hugely expensive (perforce, TFS), doesn't match the use case (same), hugely outdated (SVN), or terrible (TFS). The main competition for git is Mercurial, and a big reason git won out over Hg is because of mindshare traction and network effect from linux kernel development and then github.
The biggest problem now is that so many git fans are afraid of criticizing git's shortcomings.
Indeed it feels like most competitors are competing by offering less. This is our way! This is easier! But you're not going to win the alpha geeks over with that path. Better needs to be bigger, needs to enable more, and we're just not seeing those offerings materialize; it's unclear how you would be better or bigger.
Having the core abstractions that work & are flexible enables bountiful innovation & improvements. Git not only started with sufficiently malleable core ideas, but it's had endless features, optimization, and tuning baked in over the years. It's almost too much to comprehend. Shout out to Taylor Blau writing on the Github Blog: the man has been doing an amazing job covering what's happening in with the Highlights From Git series, since September 2018. It's really given me a sense of how much work keeps being poured into git, has given me a view of how incredibly expansive the git ecosystem is. https://github.blog/2018-09-10-highlights-from-git-2-19/ https://github.blog/tag/git/
reply