git is a tool, not a discipline. It's made to facilitate work, not to create a whole knowledge domain unto itself.
I wouldn't fault a seasoned and well trained mechanic for not knowing the specifics of a specialty tool necessitating the need to find the manual; similarly although git is the current VCS-ish thing of choice right now, it doesn't represent all of computer science.
I dont know if that answers "who cares", but a mechanic that does not know how to do something they need to do multiple times every day - there is a skill gap. While CS is about theory, I would expect a CS grad to have used all of the basic programming tools and more.
If a codebase has no VCS.. that seems almost ideological. I've done a git init on a linux file system to understand patch changes.
With that aside, what does disaster recovery look like without VCS? Remote backups ate an obtuse form of VCS.
If your laptop explodes, are you losing months of work? I mentor junior devs to push daily, if their laptop blows up I want them set up again in 30 minutes with at most one days worth of work lost (because they push their branches remotely, if only for the redundancy. Doing so daily makes it easy to recreate what was lost, compared to a week or two of effort).
Without VCS, integration is s larger challenge. It can be done, but continuously and also efficiently?
Seemingly we are talking about non collaborative code bases, a vanishingly small subset of projects. Most software is developed by teams.
Last, it is so damn easy to run 'git init'. My last job - the team used git locally and then did the stuff in TFS when they finally had to. The point is how easy and useful it was. The other guy that did his own thing, did not use VCS, his stuff was scary. His code was disaster if it stopped building, of if we lost his laptop.
Which is to say, VCS is an underpinning for CI & CD, DR, and is stupid easy to get the init setup done. Just about any codebase - yeah. Even if that means doing git locally and then throwing it away.
It is different to choose to not use all the tools compared to not being able to use them, and yet another to be unwilling to learn them either due to prejudice.
First, VCS is a generic term. Saving files to a backup is a VCS, zipping and sending files via email is a VCS.
What kinds of system use VCS as their underpinnings? Build systems, disaster recovery systems, deployment systems, more... Without VCS, you can't have those systems, and which code bases require none of those systems?
Perhaps we are talking mostly demo projects, small ad-hoc scripts. Would you posit other examples perhaps? My perspective is that it is so trivially damn easy to get a VCS set up locally, even a distributed one, that while - yes - you can live without it - in what cases should you really be living without it? Particularly in light of all the downstream dependencies of a VCS.
Maybe we disagree on the ROI of VCS? I can understand someone not building a CI/CD pipeline because it is kinda costly and maybe won't be used enough to justify it. With Git (VCS), there was a time period where I was new to it and was corrupting files left and right. Getting past that, the cost to set up & use is absurdly tiny, my daily workflow has had no issues for years now. Perhaps there is a difference in perspective there? That you view the ongoing cost to be really large? So much so, that a cat walking across your keyboard is so rare and the daily pain so large, that you have a different perspective on the ROI?
> the current VCS-ish thing of choice
It's not like they're using mercurial instead. There's a lot of concepts here they should be familiar with.
> the specifics of a specialty tool
Are you calling VCS specialty in the context of a CS degree? I wouldn't.
I feel like there's a line where we expect some on the job ramp up. Version control was not ubiquitous 20 years ago even if it technically existed in some early form. We honestly weren't really using SVN/CVS much back then and git wasn't invented 20 years ago. Containerization is another example where it was not ubiquitous even 10 years ago.
What if some new technology becomes fairly ubiquitous across the industry? There's some line where you need to accept people won't be taught this in a CS degree. There's a reasonable assumption that you'll learn on the job and also continuously throughout your career.
>Should they also be taught containers? Yes, because that's how things are done today while 20 years ago they might have all ssh'd into the same server running the development environment and 30 years ago they would have all sat in the same computer lab. And 'taught' in a sense that lists them a few good documentation resources to get them up to speed while using a provided image.
And if they end up with an actual degree they should have covered both hypervisors and containers in an operating systems course.
CS grads don't need to know VCS, but software engineers do.