I find hg much more pleasant to use than git, and can generally still work in git based teams while using hg.
I find pijul's approach much more interesting than git's, and look forward to pijul (and others :) pushing forward how we do revision control.
I don't believe git to be the end of the evolution of revision control systems (which for me has looked like cp -> rcs -> cvs -> svn -> git|hg), and find git lacking enough that I look forward to what the next generation does.
Would I argue that you personally should branch outside of your git centric world? Of course not! Just as I've worked with many devs who live their lives gainfully employed only knowing Java, or sys admins who only know Microsoft, it is up to you as to if you wish to explore different approaches and styles to achieve your end goal.
My point is that even if you do get into one of those other communities, you are still going to have to learn how to use git because so much of the world uses it. You will need it either for your job or because the open source project you want to use is on it. You can't skip learning git.
If you don't mind that, then go for it. For me, I don't want to use my limited capacity for learning things on learning a second (or third, since I still have SVN usage somewhere in my brain) SCM.
I’m not saying that Git is never used in game dev (it absolutely is), I’m saying that not everyone will have to learn it, or ever touch it.
It's a fine point, and quite reasonable. It is however I think important that we don't all take your approach.
How likely is it that Fossil will displace Git? If you believe it is likely, then learning it, and using it for projects, may be time well spent. But even then, it'll take so long that you will still have plenty of time to adapt. So perhaps it is something you should keep an eye on, but not worth investing in now. If you find Git to be a pain, then a better investment right now, which pays off right now, would be to figure out what you can do to get along with Git, and thus most developers.
You have to treat learning as an investment. Which means, you have to think about about returns on investment. And just like regular investments, it doesn't matter what people who don't pay attention think.
Also, I wouldn’t put the choice of SCM at the same level as the choice for OS.
But sysadmin'ing Windows vs. Linux is basically two different jobs. You certainly wouldn't hire someone to be a Linux admin who'd only worked on Windows servers before.
We’d absolutely switch over if there was some feature we wouldn’t get elsewhere. But it’d need a couple of months/years of sustained advocacy.
There are already experiments in this area[1], but I don't think any are ready for mass adoption yet.
The fact that it's 2022 and we're still working with red/green line-based diffs is absurd. Our tools should be smarter and we shouldn't have to handhold them as much as we do with Git. It wouldn't surprise me if the next big VCS used ML to track code changes and resolve conflicts. I personally can't wait.
A new VCS isn't really needed.
It turns out, both kind of need the same things, and if you do it right, you get better merging with text than Git currently does.
Source: I'm working on the next big VCS. It's not Pijul, though.
Not much else is done, unfortunately, because this VCS depends on some other software that I'm struggling to write.
Hmm maybe. I think this will come, but it may be more broken up through build tools that include this functionality, not a singular VCS. I think aggressive linting is starting to help with whitespace and formatting adding noise to diffs. We're seeing progressively more integrated build tools (Cargo, NPM, vs anything C/Java).
Personally, my bets are on the next VCS being more "workspace" centric as a next-step evolution. Any big change is going to come as we already change how we work. We're starting to see a lot of various tools that are basically VM/Container workspaces that you work out of. Cheap to spin up for each feature, instead of branching/pushing/pulling on one local repo. I think "thin client" reproducible workspaces are the next evolution.
What will VCS look like when everything is always-connected and (maybe?) cloud hosted? Maybe it'll allow "sharing" of workspaces, so you can build big features as a team (instead of feature branches being pushed/pulled). You'd certainly not store the "fat" history of changes locally, and big assets/binaries/etc would be better supported. Maybe it'll be built into one of these virtual workspaces as an overlay-fs, so its transparently auto-saved to a central store instead of manipulating the existing file system like git.
Btw A lot of people who say rebase is dangerous use git stash and have no idea that stash is one of the actual dangerous things to do, much more dangerous than rebase, and not any easier than branching.
“If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms.”
What’s dangerous is using things one doesn’t understand and not asking how to use it or reading up on it.
I mean, once I understood the major concepts of git, and understood how its model was fundamentally different from something like svn or cvs, it wasn't that hard to use it. Sure, it took time to learn, but given that it's a tool so integral to my working life, I'm fine with spending a little more time learning it if it makes me more productive in the long run.
I use mostly Jetbrains IDEs, I'm sure their git/VCS integration is pretty good, but I stick to Sourcetree plus occasional command-line for most stuff.
I'd probably fail a git-oriented interview section because I'd fail at the command-line for some common things for which I just use Sourcetree. In any case though with my approach I've seen I generally get a much better overview of code changes and branching strategies and have a more flexible and convenient experience that many other coworkers over the years.
I don't want a bitbucket account and never bothered to check how often it would phone home to ensure you had an up-to-date bitbucket account. I think the Sublime folks have a better track record here and I fully expect Sublime Merge to get to the point where I'd want to buy it if I wanted a git GUI.
Unfortunately for Atlassian, by 2011 Bitbucket already lost out to Github and they hadn't realized it yet.
If Fossil had good support for binary files I would have considered switching from Git (since Git LFS is just yuck), but from what I've heard it doesn't look too good.
Teaching colleagues and using tools they can put on their résumés is pretty important. Iconoclasm isn't always a good way to live (or do business).
I thought I'd learned my lesson, switched to Git, etc. Then I started rolling out SaltStack and turned myself back into that guy. I finally gave up when I realized I was the bottleneck on so many people's work. Went back to plain old written deployment guidance about three years ago. Now I'm looking at containerization and orchestration tooling and worrying if I'm making the same freaking mistake yet again.
It's such a difficult balancing act, especially as one moves into management. I could, by fiat, mandate tooling (and do). But will I regret my possibly poor choice in 5 years? I don't know—let's find out!
Basically, if you have the repo and the fossil binary you have everything. Is this better? I never saw a lot of advantages in my style of work, but i could see this being huge for someone who has intermittent connectivity. Or maybe someone who wants to use the ticket tracking, etc without setting up a separate server or public instance.
I just love that fossil exists and there is a diversity of opinion on how things can work.
I think it's pretty interesting in that it's a hugely replete web application written in C that does all sorts of stuff... bug tracking, wiki, etc.
An scm can be better, some probably are, but it won't match these other traits.