I mean, ideally, that'd be great. I don't think there's any fundamental reason things can't be this way, many of these complexities are completely incidental, rather than inherent.

> Is it really too much to ask a newcomer to invest some hours into learning something these days?

No, but when I'm learning something, I prefer for my time to be spent on important stuff, not wasted unnecessarily.

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.

https://github.com/digitalocean/tos

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.

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.

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.

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.

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.

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.

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.

This isn't rocket science.

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

I wouldn't call installing a vcs "learning to program".

A better analogy might be: "Can you imagine, opening an A4 notepad to take lecture notes took us some hours"

Not a perfect analogy I know but "setting up tools to start learning" != "learning completely"

Either way, I don't really get this kind of aggressive resistance to making things more accessible...

And using a notepad to take notes relies on your having learnt how to read and write in general, which took a significant amount of time.

That being said, I agree with it being good to try make things as accessible as possible, so long as it doesn't impact overall utility.

The commenter is referring to the tooling around git, wasting valuable teaching time.

For example, most people will only ever have one ssh key on their device. Having to setup the keyring, and keeping aware of its nuances, is a waste of time.

Git is a wonderfull tool for exploring a development process unlike anything that’s existed in other domains, but in my experience it is mostly used as a write only tool to deploy code.

It's really important to me that whoever I'm teaching is able to really understand each piece and build their intuition as we build things up.

FTP is a bit orthogonal to the use case here. That being to have her code pushed up to a central repository, able to clone it on her other computer (laptop), and enable me to review it or tweak things.

Never before have humans experienced such an overabundance of learning materials (YouTube, blog posts, StackOverflow, books, courses, etc). So much of it easily accessible and available for free. The tooling continually improves.

What most people are missing these days is a goddamned attention span and a dash of humility.

This isn't about mastering source control systems (that can take years). This is about taking a complete newcomer with absolutely no background whatsoever from nothing to something in three hours, which is an absolute miracle in and of itself. Will you also complain about how hard it is to learn how to swim, paint, use chopsticks, change a tire or play chess?

Quantity unfortunately doesn't mean quality.

Without experience it is hard to separate low quality from high quality content. And then there's are.many things which are outdated ...

Start QBASIC

Enter:

PRINT "Hello World!"

Run the program.

Congratulations, you wrote your first program and have become a software developer

    python3
    > print(“Hello world”)

  >>> print(“Hello world”)
    File "<stdin>", line 1
      print(“Hello world”)
            ^
  SyntaxError: invalid character '“' (U+201C)

Oh and probably you should be using a package manager to do it so figure out which one’s on your system first and learn its interface.

Oh and it’s best practice to create projects in a virtualenv so install that too, and learn how to use it.

Start ipython (or the interactive interpreter for your language)

Enter:

print("Hello World!") See the result!

When you use git directly, you at least get all the tools to solve your problems. When you use (most) frontends, you don't. And you learn: If there are errors, just start over - much easier!

This is not the fault of developers, it's shitty tooling + bad tutorials + bad defaults in tooling + unsuitable defaults in git (git's defaults are for the workflow used in the kernel, NOT the workflow most git users use, which is completely different; it's actually amazing that the same tool can support both workflows pretty well, with the right config settings).

On Windows I use TortoiseGit and although I find certain things to require a few more clicks than I would like, it has been able to handle very nearly everything I have ever needed to do with Git. Management of worktrees seems to be the only thing I wish it would add, but once you add a worktree folder using the command line, it is then able to work with it perfectly fine.

It even recently added dark mode!

Every other Git GUI I've tried only seems to cover "pull", "merge" and "push" workflows competently, at best. If you want to do anything more complex like even a slightly interesting rebase, then they seem to be a nightmare. So I completely agree with your assessment there.

I don't really know Git CLI very well and the thought of using it exclusively seems very inefficient and painful. As with any decent GUI program, TortoiseGit exposes available functionality reasonably well and you don't have to resort to reading a large manual to become proficient.

For both Linux and Mac (which I use rarely to work on issues with a cross-platform Electron app), I have yet to find a Git GUI app that I am satisfied with.

When I looked, Fork appears to be pretty good, I should probably at least try the evaluation and if it's okay just pay the seemingly reasonable $50 fee, but it's a pity it doesn't also support Linux.

I know GitKraken works on Linux, but it's one of those clients which is not nearly powerful enough for my needs and it costs $60 a year, I think GitKraken's popularity is largely driven by their eye-candy and that many Git users don't really understand Git beyond the simple workflows.

As a novice, you don't understand the benefit provided by the tools, so you don't bother learning them. As an expert, you've forgotten the shape and impact of the massive learning curve faced by the novice so you don't understand why they don't bother overcoming it.

I suspect the 80/20 rule applies here - a GUI provides 80% of the value of a source control system, 80% of the time. If occasionally you do have to delete everything and start again, that may actually be a more effective technique than spending a lot of time learning Git beforehand, despite how crazy it looks from the perspective of an expert.

Either way, GitHub's authentication change doesn't seem to be the problem people are making it out to be.

https://git-send-email.io