I feel like there isn't much of an argument made here. It's just "we chose VCS and we're clearly right" with the veneer of examples. > Git is clearly not a VCS

I feel like there isn't much of an argument made here. It's just "we chose VCS and we're clearly right" with the veneer of examples. > Git is clearly not a VCS, and it has never tried to be one, and people calling it one doesn't change that. The absense of a progressing version number and lack of a definitive timeline, not to mention all the many "unnatural acts" you can do to a git repo are sufficient arguments to settle this point. OK - all of these things you can get by having a central authority thereby creating a VCS (by your definition) out of git. So git matches your definition of a VCS under constraints you already have. > But in many cases Git is an adequate substitute for a VCS, you just have to augment it with an out-of-band definition of which tree is the 'definitive', and settle who gets to define what 'a version' means. This is why github exists in the first place. Oh great so you agree that you can make git into a VCS based on your definition. So what's wrong with git again? >In FreeBSD we have insisted on "proper version control" from day one, 23 years ago, and while it is a decision we should revisit periodically, everytime it has come up, it has been overwhelmingly confirmed as "the way we do things here". Ah, it's just not "the way we do things here". That's what's wrong with git. Got it. An argument that might make some sense to me is "the beneficial collaboration features we'd get out of git isn't worth the switching costs". But I just found this written so matter o-factly ("It's impossible to refute this line of reasoning in my opinion.") for something that seems to make no actual point at all