[srer]

There are significant pockets of non-git users in the developer community ;)

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.

[cortesoft]

Sure, their are developer communities around the other SCMs, and many are passionate about those alternatives.

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.

[olig15]

That’s not true. I’m a gamedev and have never had to learn git. The closest would be downloading a zip from GitHub. Almost all game dev is done on Perforce due to the enormous asset sizes we work with.

[davemtl]

Also in gamedev. Git doesn't work for larger AAA projects, as it often chokes on the amount of data that stored by production teams, even when LFS is used. Perforce can handle huge binary files relatively easily in comparison.

[johnny22]

so you're saying contribute to absolutely no 3rd party code? The person is saying that if you spend time outside of your VCS bubble, then you will end up using git, even if you don't like it.

[olig15]

Correct. The dev teams working on the ‘client’ part of the game (ie, the game) don’t have time to be contributing code to open source projects, but we don’t use much open source code anyway. But other teams within the company will be using Git for server code, and other non-client side work.

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.

[nine_k]

With insane schedules of game dev, I'd be surprised if they could contribute something back, except by open-sourcing their older code.

[srer]

Reminds me of discussions I had in the early 00's! People would say "Linux is cool and I'd like to try it, but Windows is where all the jobs are".

It's a fine point, and quite reasonable. It is however I think important that we don't all take your approach.

[bborud]

The thing about Linux in the early 00s was that to a significant portion of developers, it was already obvious where things were headed. Anyone not seeing the potential wasn't really paying attention. And one shouldn't care what people who aren't paying attention think.

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.

[kelnos]

I think it kinda doesn't matter in this context, though. You can pick up enough in an afternoon to be productive in a new VCS. If I worked at a Mercurial shop, I wouldn't disqualify a candidate that had only used git.

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.

[cortesoft]

Do you really think other SCMs are going to take over git like Linux has in the server industry?

Also, I wouldn’t put the choice of SCM at the same level as the choice for OS.

[inferiorhuman]

Eventually? Sure, nothing is forever. But the replacement won't be by something older like p4 or hg. The real question is: has the replacement been written yet?

[ghoward]

Not yet. I'm getting there though. :P

[yjftsjthsd-h]

The bar is a lot lower; sure, you might want to be able to use git, but if you're only using it enough to interoperate you don't need to know how to do fancy stuff and can get by with a subset of common commands (if you only clone, pull, commit, and push, then you can just about s/hg/git/g) and ugly fixes (why learn to rebase when you can make a fresh clone and hand-pick changes?) without feeling bad about it.

[Bjartr]

The existence of tools like hg-git mean you can work with git repos without knowing the git tool itself.

[Aeolun]

I’m just waiting for the next VCS that brings significant changes.

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.

[imiric]

The next big thing will be semantic code versioning. I.e. a tool that understands language syntax and can track when a symbol is changed.

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.

[1]: https://github.com/GumTreeDiff/gumtree

[pid-1]

You can use .gitattributes to set which program will be used to generate "diffs".

A new VCS isn't really needed.

[vineyardmike]

> The next big thing will be semantic code versioning. I.e. a tool that understands language syntax and can track when a symbol is changed.

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.

[ghoward]

In my opinion, it wil be both semantic code versioning and better support for versioning binary files.

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.

[pdimitar]

Do you have any preliminary material to read through about this VCS?

[ghoward]

Just poorly written design documents. https://git.yzena.com/Yzena/Yc/src/branch/master/docs/yar/de... . I'm still hashing out the details of the diff and merge algorithms.

Not much else is done, unfortunately, because this VCS depends on some other software that I'm struggling to write.

[yjftsjthsd-h]

If they ever fix the performance issues and get a little polish, the patch-based DVCSs (pijul et al.) will be a great improvement in usability. If I were guessing, I bet on that as the next step (given the understanding that predicting the future like that is a fool's game).

[normie3000]

Patch-based like svn?

[yjftsjthsd-h]

Sorry, I didn't use SVN enough to answer that. Basically, they're distributed VCSs like git, but where git stores commits, that is, snapshots of what the files look like at a specific commit, patched-based VCSs in the darcs "lineage" store diffs. Obviously the end result looks similar - git gives you diffs by comparing commits, darcs replays diffs to instantiate what the files actually look like at any given time - but it (allegedly) makes it much easier to handle arbitrary merges and do things like maintain a branch that's just like another branch but with a single commit on top.

[devoutsalsa]

FossilHub sounds a like social coding for old farts.