[crickey]

Nothing against the project or talk itself. But kinda funny when a talk starts with “i bet many of you thought X was a solved problem, well im here to tell u it isnt.” Git was populare not because its somehow revolutionary, its popular because the previous options where so increadibly shit. Any alternative to git is gonna have a hard time without that advantage

[tiffanyg]

Haha - in enough ways, git is shit.

I'm not disagreeing, though. I think you're right (for the "foreseeable future"). CVS, SVN, etc., really became serious obstacles once you moved to larger projects and more distributed teams etc. Hell, they caused problems even with small colocated teams.

I think it's clear that git (and its forerunners, esp. "BitKeeper") meets a solid "good enough" standard. Potential competitors from that era, including, in particular, "Mercurial", largely fall into categories of "trade-offs".

But, I am, personally, very happy to see the work that's been done with "Pijul", including completing a "theory of merging".

I don't think Pijul has much of a chance in even 10+ years of replacing git (and "GitHub", part of the success story of git). But, I do think it'll see some use, become a solid foundation for some projects, and, there's a reasonable chance it will influence or become the foundation of some "next git" and/or future versions of git.

With the caveat, of course, that forecasting anything on those kinds of timeframes is even more of a fools errand now than it was even ~15+ years ago (about when git was first developed).

[imiric]

> Potential competitors from that era, including, in particular, "Mercurial", largely fall into categories of "trade-offs".

Which "trade-offs" are you referring to?

Mercurial was, and still is, a solid DVCS. It's not often used today because it lost the popularity contest, due to several reasons[0], but technically it's as good as Git, and functionally it's even better. It has a much saner and friendlier UI, which is the main complaint about Git.

[0]: https://news.ycombinator.com/item?id=37095925

[imiric]

Git itself might not have been revolutionary, but the concept of distributed version control certainly was. Git wasn't the only tool from that era to adopt this model, but it's fair to say that it has won the popularity contest, and is the modern standard in most projects.

Mercurial, Darcs and Fossil are also interesting, and in some ways better than Git, but Git won because it had the persona of Linus behind it, one of the most popular and influential OSS projects using it as proving ground, and a successful and user friendly commercial service built directly around it, that included it even in its name. All of this was enough for Git to gain traction and pull ahead of other DVCSs, even though in the early days Mercurial and Bitbucket were also solid and popular choices.

I used and preferred Mercurial for a long time, but ultimately Git was more prevalent, and it felt like swimming against the current. I feel like that also happened with Docker (Swarm) and Kubernetes, where k8s is now the de facto container orchestration standard, much to my own chagrin.

[stakhanov]

> previous options where so increadibly shit

I entirely disagree. Git was not an okayish solution to a problem that previously didn't have any okayish solutions. Git was trying to solve a new problem, and, as it turns out, it's a problem that a majority of git users don't have, and don't intend to have in the future.

I use SVN to this day, because I seriously believe that it's a better solution to the centralized version control problem than GIT. After SVN, centralized version control was basically a solved problem (or, at least, we had an okayish solution), so the next generation of tools (GIT, BZR, HG, FOSSIL) tried to solve a different problem, namely distributed version control.

But they made a complete mess of it (at least git did, I don't know the other distributed ones particularly well). A majority of git projects use centralized workflow and are subsetting the use of git features to only the ones that straightforwardly correspond to things that svn can do as well, and can do more easily. And the cost was a much more complex/convoluted mental model that a majority of git users don't truly understand in full detail, which gets them in trouble if edge cases turn up. Hence this joke [1]. With things like [2], you're basically seeing git becoming a parody on itself.

[1] https://xkcd.com/1597/

[2] https://westling.dev/b/extremely-linear-git

[pastage]

Edit: I have heard this before but it is never specific, in what way is it easier? I never needed the big selling points of SVN, binary files (not good enough for me at the time), controll etc.

[fasterik]

Git works well enough for projects that are essentially similar to the Linux kernel, i.e. it's designed to be used by programmers working primarily on text files. For projects that have non-technical people collaborating with programmers, or frequently changing binary assets, there is plenty of room for improvement over git.

[jgalt212]

Yes, that's why game shops don't use git (in general).