I get the argument but I disagree. Git is meant for software developers on projects complex enough to warrant using SCM.
Using SCM for teaching development to newbies is already adding unnecessary complexity (even in a collaborative setting, flows are complex enough to distract from more fundamental topics).
If you're a software developer getting to the point where using git is needed you should absolutely know the core concepts behind public key cryptography, it's going to come up everywhere and you can fuck up big time by publishing the wrong part.
It may be meant for software developers but has legitimate value in other domains. For example, DigitalOcean has their legal team use it as a way of providing diffs on their terms of service and other policies. This type of use case is where it benefits everyone, in my opinion, to reduce the friction to get started.
There are plenty of text file versioning use cases I think, from configuration files for system administrators to LaTeX papers for science students who could benefit and should have an easy path to using it.
This would be a reasonable point to make if there were reasonable alternatives for simpler version control. But for better or worse the world has standardized on git for all version control. If you want your "two phd student implement a new algorithm in a small python/julia package" to be found/used/talked about you need to be on github.
Heck even if you want to host a static site you probably want to just be on github these days.
Yet to me there is no reason for version control to be this complex. The current github + git universe is locked in, but I don't see why it should be optimal.
> Git is meant for software developers on projects complex enough to warrant using SCM.
There is no such thing as a project not complex enough to warrant a SCM/VCS. There's probably an argument that there is a case where a DVCS is unnecessary, but if you aren't actually doing distributed work there's no reason you need to be aware of more complexity in a DVCS than a non-D VCS.
> There is no such thing as a project not complex enough to warrant a SCM/VCS.
I have a program I wrote that helps me straighten scanned images in bulk. It took maybe an hour to write because I did it in D and was not familiar with the language. Though I have used it for years now and made a few tweaks I have never felt the need to have it in any kind of source control.
> Git is meant for software developers on projects complex enough to warrant using SCM.
I and most developers I know use git or similar for projects of any size, often even if it's "just" a single file or a "one-off" change (because it rarely stays that way).
I would have agreed in the days when Subversion was the closest you could get to "easy version control" but these days in my eyes "the point where using git is needed" is not far from the point where you start making changes to an existing file.
I think this way overestimates the value of both Git and source control in general for a lot of projects. Is this the result of the now common development methodology of using as many dependencies as possible or something?
It isn't that hard to just make a backup before you do anything messy. That's sorta what I'm getting at: people are using git as a really overcomplicated backup solution. It has the same problem: you forget to commit before making changes and you're still hosed.
Okay, but if you need to do "a backup" more than once, you will inevitably come up with your own shoddy versioning system, even if it consists of littering your project with files named "Copy of 2017-04-20_main_v1 (17).bak.new.old.bad.cpp~".
The alternative is just doing what you always do on every project: run "git init" and occasionally do a "git add -i && git commit". Even if you end up with a lot of non-descriptive snapshots name "WIP" at least you have something resembling a chronology and you can track changes across multiple files at the same time.
If your hobby projects mostly consist of single files with thousands of lines that are easy to unambiguously make copies of for backups, I won't judge you, but your experience is definitely not universal.
> The alternative is just doing what you always do on every project: run "git init" and occasionally do a "git add -i && git commit".
Or I just let my backup software handle it. Automated daily backup supplemented with manually initiated backup if I need a specific point-in-time snapshot.
Part of the problem is we were all newbies at some point.
I remember the first time I tried to use SCM. It was a collaborative project in college, and our professor recommended we set up a CVS repo (at that point in time, he probably should have recommended SVN, but we didn't know that). We spent about an hour trying to set one up, and eventually concluded it was a waste of time and that we'd just e-mail each other .tar.gz files of the repo and manually sync them. Eventually we did break something and have to go back to the last .tar.gz to un-break it, which wasted another hour or so, but with the friction we'd seen trying to set up CVS, that still seemed preferable to trying SCM again (although it also showed that SCM would have been helpful had we been able to set it up).
GitHub with a password is much easier than setting up a CVS repo as a newbie, and had that been an option then we likely would have succeeded. But I'm much more doubtful that we would have tried and succeeded at token authentication; I also remember how mystifying I found it the first few times I worked somewhere that required it, even understanding the underlying concepts of public key cryptography. The problem is understanding the tools well enough to get it working, and working across operating systems (Linux doesn't have PuTTY; Windows doesn't have the Linux command-line tools; etc.).
When I eventually started using SCM reliably, it was with Mercurial + BitBucket + a password. I recall that I kind of knew I should set up a token, but my first few attempts were unsuccessful (largely due to most instructions being Linux-focused, and being on Windows), and thus I kept using a password for years because making progress on development seemed more useful than figuring out a token. I did use randomly-generated, lengthy, unique passwords, so the risk of using a password seemed pretty low.
So I think this is a bad thing for newcomer-friendliness. Perhaps it is an opportunity for GitLab and whatever other competitors still exist. But I would have rather seen it remain an option, perhaps based on new users choosing whether they're new to Git (allow passwords) or experienced (require tokens, but be able to change it in case they're only experienced with Git, and not with tokens).
Understanding the fundamentals of public key cryptography is a worthy pursuit. Memorizing the idiosyncratic flags of yet another command line tool (or looking them up in the man page every damn time like most people do), instead of having an interface that doesn't require you to relearn it every time you use it, isn't.
Using SCM for teaching development to newbies is already adding unnecessary complexity (even in a collaborative setting, flows are complex enough to distract from more fundamental topics).
If you're a software developer getting to the point where using git is needed you should absolutely know the core concepts behind public key cryptography, it's going to come up everywhere and you can fuck up big time by publishing the wrong part.