[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.