Git password authentication is shutting down
github.blog
github.blog
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?
https://docs.github.com/en/get-started/quickstart/set-up-git https://www.atlassian.com/git/tutorials
This one's always fun: https://learngitbranching.js.org/ https://www.tutorialspoint.com/git/index.htm
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.
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/inst...)" than burning https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/de... and booting it up.
Or are you saying that you audit the bits of the ISO yourself before burning it?
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.
To explain: She wants to eventually work as a developer and has a project in mind guiding her. I started her with the simplest possible steps and she's been learning html & css for a few weeks now with some great progress. She got the the point where she was starting to have multiple projects she was building for learning. In addition, she was starting to feel the pain of "this project is on my desktop, but I am going to be away from home for a week and will only have my laptop." For those reasons (as well as the benefit of introducing GitHub as a place of collaboration), we took some a few hours to cover git and the terminal.
It didn't seem like we jumped to it too early and after those three hours she had the basics which is good enough to ensure her projects are safely replicated to GitHub and available for her no matter which machine she is on.
But, if this person's goal is about creating a web application then version control is a good skill to have. I remember the days when source code for a web application was something we could zip up and hand to a client. But, these days, more than likely you have a remote server somewhere and you need to SSH into it and from there you could SFTP the files but at that point why not just use git and it's branch management. Obviously, there are more arguments that can be made for learning git.
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.
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.
> 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.
Using GitExtensions means I can use Git as easily as any other tool, I never give it a second thought. I see the command line commands being executed, but never think about them. The flipside is I'd be knackered if I had to use the command line only.
This is once of those scenarios where subscription for an enterprise might be a thing, but makes no sense for me. The JetBrains model would make sense and I could justify that.
You just don't get new features.
My issue is that I do not get £5 worth of value each month from GitKraken. I get value every couple of months, and it is to explain to other people what they are doing wrong rather than direct value for me.
The risk is that they have to keep "doing stuff" to justify a subscription and we will end up with a new email client.
git stash
git reset --hard master
git pull
git stash popMy git config has fast-forward only for pulls and I habitually use --ff-only for any pull :)
I actually thought "git pull" did "git pull --rebase" by default (this may be what you get from running `git --configure` without modifications?), but maybe I've just been configuring it that way. You can achieve this in your global Git configuration by setting "pull.rebase" to "true".
I don't think it's sane behavior for "git pull" to do anything else besides rebase the local change onto the upstream branch, so I'm surprised it's not the command's default behavior. Has the project not changed the CLI for compatibility reasons or something?
When do you ever want a "git pull" that's not a rebase? That generates a merge commit saying "Merge master into origin/master" (or something similar) which is stupid. If you really want to use actual branches for some reason, that's fine, but "merge master into master" commits are an anti-pattern that if I ever see in a Git repository I'm working on or responsible for, results in me having a conversation with the author about how to use Git correctly.
I believe you are incorrect however. "git pulll --rebase" will not ever rewrite history from the origin repository. It will only ever modify your local unpublished commits to account for new commits from the origin branch. If your change and the new commits from origin aren't touching the same lines or files, then the update is seamless [1].
If there is a conflict because your change and a new commit from origin both changed the same line in the same file, this can result in a merge commit that you need to resolve. But you resolve this locally, by updating your (unpushed, local) commit(s) to account for the new history. When you complete the merge, it will not show up as a merge commit in the repository -- you will simply have simply amended your local unpublished commit(s) only to account for the changes in upstream, and you will have seen every conflict and resolved each one yourself. When the process is complete, and you've resolved the merge, you'll have a nice linear branch where your commit(s) are on the tip of the origin branch.
The flag "--ff-only" basically just means "refuse to start a local merge while performing this operation, and instead fail".
Because of the potential for these merge conflicts, it's a best practice to "git pull" frequently, so that if there are conflicts you can deal with them incrementally (and possibly discuss the software design with coworkers/project partners if the design is beginning to diverge -- and so people can coordinate what they're working on and try to stay out of each other's way), instead of working through a massive pile of conflicts at the end of your "local 'branch'" (i.e. the code in your personal Git repo that constitutes unpushed commits to the upstream branch).
Additionally, all of the central Git repositories I've worked in in a professional context were also configured to disallow "git push --force" (a command that can rewrite history), for all "real" branches. These systems gave users their own private Git repo sandbox (just like you can fork a repo on GitHub) where they can force push if they want to (but is backed up centrally like GitHub to avoid the loss of work). This personal repo was very useful for saving my work. I was in the habit of committing and pushing to the private repo about once every 30m-1h (to eliminate the chance of major work loss due to hardware failure). Almost always I'd squash all of these commits into one before rebasing onto master, so that the change comes in as a single commit, unless it would be too large to review.
In the occasional circumstances where I've legitimately needed to rewrite history for some reason -- say credentials got into the repository, or someone generated one of these "merge master into master" commits -- then I would change HEAD from master to another branch, delete master, and then recreate it with the desired state. (And even that operation would show up in the system's logs, so in the case of something like credentials you'd additionally contact the security or source control team to make sure the commit objects containing the credentials were actually deleted out of the repo history completely, including stuff you can find only via the reflog.) Then contact the team working on the repo to let them know that you had to rewrite history to correct a problem.
I would recommend disabling "git push --force" for all collaborative projects. If you're operating the repository, you can do this by invoking "git config --system receive" and setting "denyNonFastForwards true". In GitHub there's probably a repository setting switch somewhere.
Once professional software engineers start working with Git all day long, they quickly get past the beginner stage and the need to do this kind of stuff is very rare.
[1] It doesn't mean the software will work though, even if both changes would have worked in isolation. You still need to inspect and test the results of "git pull (--ff-only)", since even if there are no conflicts like commits that modify the same lines as yours, or there are conflicts that Git can resolve automatically, it's possible for the resultant software logic to be defective, since Git has no semantic understanding of the code.
# git branch -av;
# git remote -v;
# git reflog; git help reflog; man git-reflog
# git show HEAD@{0}
# git log -n5 --graph;
git add -A; git status;
git stash; git stash list;
git pull --rebase;
#git pull --rebase origin develop
# git fetch origin develop
# git rebase origin/develop
git stash pop;
git stash list;
git status;
# git commit
# git rebase -i HEAD~5 # squash
# git push
There's a way to default to --rebase for pulls: is there a reason not to set that in a global gitconfig? Edit: From https://stackoverflow.com/questions/13846300/how-to-make-git... :
> There are now 3 different levels of configuration for default pull behaviour. From most general to most fine grained they are: […]
git config --global pull.rebase truethis is not correct. git rebase, as with git merge, will automatically resolve conflicts using a 3-way merge algorithm.
> It will only ever modify your local
this is correct.
> unpublished commits
this is not correct. git rebase (in its default mode) rebases all commits that are not upstream onto the upstream. it has nothing to do with whether they are published or not. if you have a published feature branch, and git pull --rebase into it, git rebase will dutifully rebase all your commits.
After reading more about it, you are right about that. It will only apply your commits to the tip of remote.
I get pushing every day, but how unreliable does your PC have to be if you feel you need to push every hour???
> (And even that operation would show up in the system's logs, so in the case of something like credentials you'd additionally contact the security or source control team to make sure the commit objects containing the credentials were actually deleted out of the repo history completely, including stuff you can find only via the reflog.)
You can't un-leak credentials. The only valid action for leaked credentials is to invalidate them, not to pretend that they were never leaked.
Hey, I commit and push on a branch on my fork of the repo every time my unit tests work and sometimes if they don't.
It's a single command, `gi`. My joke is "commit/push is the new save" though I'm not that bad...
No one but me has to see that branch. I rely on my rebasing skills and a library of git tools to produce a small number manicured commits out of it with no work.
It works so well. For one, if I am going from one machine to another, I can literally work and then step off my machine and continue on the other with a pull but no interruption.
At any time, I can just send someone a question with a permalink to the code as it was at that moment, and keep working while waiting for the answer.
I never have much uncommitted work in the current branch, so I can almost immediately start a new bugfix in an emergency.
> The only valid action for leaked credentials is to invalidate them,
Quoted for truth.
If you can make one that thinks in terms of git on the backend, great.
If you want to go a bit further, you could expose the underlying operations to the user. You will need to get them to reason around and interact with the minimal requirements inherent to a versioning system, namely explicit versioning and an explicit commit process, along with explicit merging and conflict resolution.
There are GUI clients that help with some of this, but you're not going to get away from some concept of dealing with branches and merges in any SCM. You hear about it less often, but you'd have the same troubles dealing with a chewed up repository in Perforce, ClearCase, or the like.
(edit: even Subversion!)
It has a few helpful hints.
GitHub's web interface is pretty good for this.
What GitHub has going for it is that it is familiar to ("a majority of"?) working developers, and that it's better than both the competition and the Git CLI itself, but from a reality-adjusted perspective, GitHub is pretty bad, too. (Then when people like me make comments like this, others wrongly infer that it comes from a history of false starts and firsthand frustration, unable to conceive that anyone would speak up on this sort of thing if there weren't something personal at stake; no way that it could just be the result of empathy for the uninitiated.)
It's pretty tragic that we've basically killed wikis —like, actual wikis—and regressed back to directories of text files managed by version control systems originally meant for handling program source code. That people then go on to call these wikis is basically an insult to history.
52028d35999a481e7cb19b14eae3bf66cb7c9c4fe2e15b56b55f3ccadffeee1f
1. Go to dev branch
2. Find file and edit it
3. Commit change
What are the steps to edit a wiki? Click edit page, make changes, add comment and submit. That sounds like almost the exact same steps to me.
https://github.com/solid/solid-rest
(It's the only link in the file.)
Make sure you don't have your thumb on the scale.
$ sha256sum "./PR?-ORLY.txt"
52028d35999a481e7cb19b14eae3bf66cb7c9c4fe2e15b56b55f3ccadffeee1f ./PR?-ORLY.txt
$ cat "./PR?-ORLY.txt"
Did you commit to source control and submit a pull request to post this comment?I'm not experienced here, but is using the GitHub website perhaps the easiest way to submit a PR, that's how I first did it and I think it worked ... I've only really used git privately and for pulling code from public projects.
But yeah, I pay for it now because it's such a significant time saver for my day-to-day. I'm always aware of what my coworkers are doing because it auto-fetches every minute. I use it for code review as well, because I find it really easy and snappy to navigate file changes in a commit (I always use split view, and I almost always have "hide whitespaces changes" on). I has a great interface for interactive rebases as well, allowing to drag to reorder commits, etc. Good built-in merge conflict resolution tool.
It used to explain itself through building your own version of git. You have a file named hash that tracks changes on each file named foo... now all the changes are in a directory named hash...now your changes have to be merged with others...
It's kind of up there with next steps after if then else fi. Some things will always be difficult, but diffs and commit and picking one of two possible diffs from two windows should not be one of them.
Just think of the "places" a change can be in (technically most of these are just labels on the tree, but they have separate commands to deal with them).
Remote, Index, working copy, staging area, stash, branches.
Those are the ones involved in the simples way I know how to make the smallest change. When you get up to stuff like submodules, LFS, subtrees then I very much understand when people get frustrated. All most of them wanted is a slight improvement over copying a folder they named myproject_v23 to a network drive.
And some statisticians and stuff only know how to use the GitHub desktop client and that works ok for 99% of them. Drives me crazy because I only use cli and struggle to help when they get blocked with the client.
GitHub Learning Lab: https://lab.github.com/
https://learnxinyminutes.com/docs/git/ #Further_resources
The question really should be why do we want to use git for version control when people really want an backup system where they can essentially update files by uploading a new version of the file.
But I think the reason is because the mess of folders they then create in DropBox and they can never find their files.
What would be great is if someone could make a TimeMachine for non-developers that uses git, because that is what they are doing in their heads anywy.
Integrating those file(s) as a submodule or subtree in a git repository would work on the development side, but people who generate those files would have no need to interface with git, and people who use git would not need to use the editor for those files to get the history they need.
Designer: Hey, I filed a bug for this, it doesn't look like the design. <screenshot of design they changed yesterday>
Developer: Um, we released that like two weeks ago; it's correct according to the design I had at the time.
Designer: Yeah, but this is the design <link to continuously updated document in web editor with no history> Maybe you can just fix it really quick today?
Doesn't have to be git, but some way to match up releases to the design document that was current at that time is quite useful.
So you could tell the designer that you have the version they sent you on Friday August 13, 2021 at 3:12 PM EDT. Did they make any changes after that, or did they mean to send you a version they made prior to that?
Is graphic designer even going to be able to merge things in their files?
It seems that "overwrite my files by data in repository" "apply my changes with message" are all what is necessary? Or is it case of multiple nontechnical people editing files together and expecting to merge changes?
Another extremely common pain is trying to "delete" a local commit.
The only thing lacking is public code spaces. I can’t even try them out without paying for GitHub Teams or GitHub Enterprise.
Wow, never heard about this (ok I don't follow all possible tech news), but why is this not clearly advertised on github itself? Looks pretty neat and seems to work fine (for what it offers) as well.
I can't find `.` on this page: https://docs.github.com/en/get-started/using-github/keyboard...
The problem is, as soon as someone needs any of the non-basic operations, they're completely stuck, and have to start out by learning the basics (which they've managed manged to avoid so far).
Plus, each implementation makes up its new terms and abstractions.
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.
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.
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.
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.
But, hey, git is sooooo superior. </s>
GitHub has done almost as much damage to version control as PowerPoint has done damage to presentations.
They don't need to know how git works, they need to know how to use it.
Just like I don't need to know the details of an internal combustion engine to drive a car, someone who only does CSS work doesn't need to know how git works to push commits. A simple GUI interface suffices there.
The problem is that the official Git GUI interface is unbelievably bad and happily lets you put yourself into situations that the GUI is completely incapable of getting out of. A default GUI that can't essentially softlock itself would be fine for most casual users.
There absolutely does. It's called Git GUI. It's right here: https://github.com/git/git/tree/master/git-gui
This will certainly be a little more difficult for newcomers, and not very discoverable, but it is there.
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.
So maybe it didn't improve your security, if you were already letting your password manager generate distinct passwords, but it almost certainly improves the median user's security, who has come up with a weak password they think is strong, and may well use that password on multiple websites.
Generating the accout password instead of allowing a user-supplied password would also work here (and incentivize the use of password managers, if enough websites did it), but I would guess getting people onto SSH keys is useful for them in general - e.g., it allows them to make 2FA or CAPTCHAs mandatory for use of high-abuse-potential features like CI or Codespaces.
> Tokens offer a number of security benefits over password-based authentication:
> - Unique – tokens are specific to GitHub and can be generated per use or per device
> - Revocable – tokens can can be individually revoked at any time without needing to update unaffected credentials
> - Limited – tokens can be narrowly scoped to allow only the access necessary for the use case
> - Random – tokens are not subject to the types of dictionary or brute force attempts that simpler passwords that you need to remember or enter regularly might be
I pretty much do the same thing, I just copy-and-paste a PAT from my password manager when I need it on VMs. The big benefit to us is that PATs are "limited", and mine only has Git repo access, so unlike my password, it can't:
- Delete repos
- Edit my GitHub organization
- Share my private repos with other users
- Add/remove SSH keys from my account
There's always the chance that a software you install on your VM would contain a keylogger (e.g. NPM/PyPI malicious libraries), so limiting the damage that your credentials can do is always a good thing.
Still, it's good to be in the habit of doing this, because sometimes you do need 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 :)
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?")
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.
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
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.
It also has an undo button to undo the last commit which has saved my ass a couple of times.
Anything but git. Git was definitely not designed for ease-of-use.
Only Linus and friends need or use 90% of git's features.
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
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).
Use literally any GUI. Alternatively, press '.'
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.
$ 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/someprivaterepoI 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?
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.
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 ...
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.
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.
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.
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).
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”)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.
>>> print(“Hello world”)
File "<stdin>", line 1
print(“Hello world”)
^
SyntaxError: invalid character '“' (U+201C)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).
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.
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.
Either way, GitHub's authentication change doesn't seem to be the problem people are making it out to be.
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.
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.
"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.
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.
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.)
That's exactly why git is a bit of a pain to initially set up.
What you need is to install Git for Windows. It will include ssh-keygen (if it's not already there) and you can do the usual dance.
It suggests SSH commands by default for me, I assume this depends whether you have added an SSH key to your account or not.
I wish there was some way of _manually_ identifying via a simple link or QR code or whatever.
I'm the same, and it's reassuring to know that I'm not the only one just using it as a free web host for personal projects.
Until starting a new job in January 2021, I "knew git" to the extent of git pull, git add, git commit -m, and git push. For everything else I just made a copy of the repo. Now I've learned a little more about branches and merge requests, but I still make a copy of the repo and copy my changes over when things go wrong. https://xkcd.com/1597/
Like you, I got some password-related warnings on GitHub, and honestly it's scaring me away. I know it'll take an hour or so to figure out what went wrong, regenerate a ton of SSH keys for every computer I own and link them to my account, disable 2FA because my phone number is in another country... I'd rather just upload a file, thanks.
The increased overhead means I'd rather just use FTP to upload some files to an HTTP server, but I don't think that such free FTP web hosts exist any more. At least, not ones with a domain that people recognise. That said, peterburk.github.com is no longer accessible, only peterburk.github.io, so maybe it is time for me to go looking for a free .com subdomain.
I'm grateful for GitHub hosting all the junk I decide to share, and I'm obviously not their target market if I'm not paying. I just wish there were a place I could drag & drop to upload content publicly.
You could do a single one per computer. You could even do a shared single one across all computers (it’s recommended against but not strictly worse than a shared password)
> disable 2FA because my phone number is in another country
Don’t use SMS for 2FA. Use TOTP (Google Authenticator or similar app. There are alternatives that let you sync) or U2F (hardware key)
(Git for Windows default installs GCM Core. Some Linux distros do to. You may even already be using it. I think I've seen some confusion in comments here and elsewhere that they don't realize they are already typing in their username/password to a GCM dialog and that's going to keep working. This is about removing HTTPS Digest auth with direct password transmission over the wire.)
I've tried setting up SSH keys many times and have somehow failed many times. The UX for security stuff just isn't there. I finally have gotten a workflow sort-of figured out and documented to remind myself in the future.
I think it's a misconception.
Unless you just let everyone write anything in your repo, one would expect that what is there is what it says on the tin.
Every public software project takes measures to stay authentic and not let random and unreviewed, potentially malicious bits in. This is how they keep their users' trust.
Very roughly, "public" = read access is unrestricted, and "insecure" = write access is unrestricted.
GCM Core is a really straightforward way to auth with GitHub and several other Git hosts. It comes with Git for Windows by default, can be installed with `brew` on macOS, and from a .deb on Linux. https://github.com/microsoft/Git-Credential-Manager-Core (it started under the Microsoft banner but is maintained by GitHub employees now).
I want to have work and personal GitHub accounts on the same machine and very explicitly choose which account goes to which repo. Too often I have changes going in with the wrong user.name / user.email or account to the point where I paranoidly reauthenticate every time and manually check each clone's .git/config.
In my ~/.gitconfig file, I've included
[credential "https://github.com"]
useHttpPath = true
Host github-personal
HostName github.com
IdentityFile ~/.ssh/id_rsa_personal
Host github-work
HostName github.com
IdentityFile ~/.ssh/id_rsa_work
edit: I realized after reading the other comments that I got the problem wrong! This would push the commits from the correct GitHub account but the commits would still have the e-mail from git's config and GitHub would link the account in the committer e-mail.
That seems like a situation where you'd `git config user.email` within your work repo(s) so that it's set locally, not globally. I also think GitHub primarily supports and envisions people using one GH account for work and personal projects.
Edit: but also, GCM Core has nothing to do with the user.email/user.name in .gitconfig. I have a similar problem where I want some commits written with my work email and others with my personal, and I always forget to check it when starting in a new repo. I push them both using a single GitHub identity, though, so your situation has an extra wrinkle.
git clone https://vtbassmatt@github.com/WorkOrg/work-repo.git
(Here's where I could tell you about all the ways in which the credential manager system in Git is deficient... I'll spare you, though, and simply say that this is close to the best we can do without a whole other layer of artifice that you probably wouldn't like.)
Went to bed early rather than finish that, and this just reminded me of it... (offhand, I wouldn't be surprised if my alias has to be something other than `clone`, but no biggie if so)
You can configure it to set your git user name/email based on your working directory, for example. This is how I keep the separation you mentioned between personal and work on the same machine
Also, it doesn't seem to solve the problem of multiple accounts; I more or less accepted I need to manually configure user.name and user.email for each clone, but the account is not part of the same config, it looks like it's stored in some other ephemeral place - maybe GCM Core, or some Credential Manager or who knows.
I only realize it was using the wrong account when I try to push and get some unauthorized error; by that point, my commit log is polluted with the wrong account so I need to do some gymnastics where I reset the authentication, manually copy over files or unstage to purge the metadata, etc.
https://alice@github.com/owner/repo
GCM will store credentials for "alice" only. Repositories that have remote URLs with a different "user@" will use different credentials.
Remote URLs without a "user@" part at all (like "https://github.com/owner/repo") are treated like the "default" user for GitHub.com, rather than a specific one.
GitHub Actions tokens are scoped to the single repo they operate in, so for anything that you need covering any cross-repository or org access the official docs immediately tell you to just use a PAT instead. But PATs have no repository scoping whatsoever, it's all or nothing. So although both PATs and GHA Tokens have these complex scope requests, it's completely missing the most basic use cases in my opinion, like creating a PR in repo X, allow installing a package from GitHub Packages in repo Y, check out code from repo Z etc. You either go full mono-repo for everything, or you use PATs for everything with no repository boundaries at all, yikes.
So no need to panic if you've been using a build system or other tool that authenticates with username:token instead of a SSH key.
Workflows affected:
* Command line Git access
* Desktop applications using Git (GitHub Desktop is unaffected)
* Any apps/services that access Git repositories on GitHub.com directly using your password
People who've put this information in a netrc file may see downstream issues in several applications which auth with info found therein
I hate it. I don't care much for the slight chance that someone gets into my github account. I care a lot more that now I have to jump hoops to get into my account myself. There's more to things than security.
You can use a git credential manager such as GCM Core (https://github.com/microsoft/Git-Credential-Manager-Core) to automate the flow from username/password to access token. (It pops up a browser window where you login, retrieves and access token for you.)
I prefer less tools to more tools. Probably a losing battle given how the field is developing.
git itself was built as an agglomeration of multiple tools bundled together and GCM Core is right on the borderline of a tool always included in the git distribution anyway on some platforms and needs to be installed on others. It's likely to always be in that "weird border space" because it requires a web browser and there isn't a pure command line equivalent.
Sorry, but I still hate it. I want less software, not more.
It's hard to picture how it could be.
Git still supports password authentication, as well as many other protocols. GitHub chose to restrict which protocols and authentication schemes are allowed on its platform.
But obviously, learning about the tools you are using is always a good idea.
My preferred "tutorial" is this one: https://codewords.recurse.com/issues/two/git-from-the-inside...
It is more advanced than the usual introductions but it demystifies most of the git concepts.
Signed: a developer with well over a decade of experience in version control, *nix, Windows, crypto, etc.
Pushes were not working. I re-entered my password a few times, checked other config settings a few times before Googling the Git error message, which led me to find that GitHub's security policy was changing.
I tried an SSH login (fail), switched to trying locally generated SSH keys.
Used PuTTY's "puttygen.exe" to make an SSH key. Did that, then found it was a newer format that Tortoise could not handle. Used TortoiseGit's copy of "puttygen.exe". Did this a few times as GitHub wouldn't accept the format that my key was in.
Gave up on GUI key generation, tried command-line and failed a few more times.
I think I looked at personal access tokens at some point.
Went back to GUI SSH file creation, and managed to upload my puttygen SSH key by copy/pasting from part of the dialog box that I hadn't tried before.
Used GitHub's "git@github.com:<username>/repo" syntax to get a fresh clone of my repo. Finally I realised that I needed to use the github URL syntax combined with "Load Putty Key" ticked and pointing to my private key
I'm still not sure if it's the right way or the best way, but it worked, so I stopped looking.
In the past, multiple people would use these computers, and would push and pull using their own github credentials. I'm talking lab computers in a research context, where there is a shared login to the computer, but where we use our own github credentials to access a shared repo we all have commit rights to.
Now what are we supposed to do? I don't want to put my ssh key, or an access token or whatever, on a shared computer. My colleagues using that computer should not be able to access my other github repos. I should be entering a password, something I can keep in my head.
But yeah, it looks like for your use case this is not a great change.
Multiple user accounts would defeat the purpose of it being a shared computer. It's a shared computer because everyone is using it for the same thing.
A lot of employers put monitoring software on their computers, and have keyloggers that can record your passwords. It's probably illegal for them to use the passwords, but I have heard horror stories where employers secretly log into their worker's social media accounts.
I'd recommending buying a U2F or FIDO2 security key, and creating a ed25519-sk or ecdsa-sk SSH key, see: https://github.blog/2021-05-10-security-keys-supported-ssh-g...
Basically, the SSH key is stored on the hardware key, and for every single git pull/git push you need to do, you must have the security key plugged in. If you're worried about forgetting the key and leaving it plugged in, you could add a password to the SSH key as well, so you're doubly protected.
We all had our own GitHub Enterprise accounts. But only one was logged on to each computer. Rather than switch out the accounts when someone else used a computer, we just included the initials of whoever was making the commit in the message. E.g. DU: Fix some bug, if Double Unplussed was making the commit.
This only really worked because no one was using a GitHub login that they also used for personal projects - only the corporate ones were connected. And it made the GitHub statistics on who was contributing what completely useless. But it did mean that we could rotate among the shared computers and push easily, and if you did need to ask someone for help when investigating a bug, you could still see who made the changes via git blame - just by looking at the message instead of who Git thought had pushed it.
Might not work for your use case, and I'm sure some readers will be horrified, but it worked well enough for us, in an XKCD 1172 (https://xkcd.com/1172/) style manner.
I guess we could have a shared github account and I could give it commit rights to the specific repositories. But that's still pretty silly that I should have to do that.
(I think the way it's structured is that Jetbrains is the OAuth provider, and Github is the relying party, which implies that you need to make sure your Jetbrains account is secure. It also means that if you want the best security you'll stick with the tried-and-true private-key-in-.ssh-public-key-on-remote solution)
Also, you can see the domain right next to the submission title.
https://docs.github.com/en/developers/apps/getting-started-w...
For a semi-trusted machine (e.g., you want to "git push" to work-related OSS from your work desktop, but you don't want your work HR/IT departments to have full access to your GitHub account if they decide they want it), make a new SSH key and configure it as a read/write deploy key for that one repo. This workflow is primarily intended for automation, but it's reasonable for this sort of interactive use as well.
https://docs.github.com/en/developers/overview/managing-depl...
But if you aren't confident of it, then at least that token only has access to a repository, and can't be exfiltrated to let somebody log in and really mess with your user account or your organization.
(All that said: I'd recommend a single-use, minimally privileged SSH key over an access token, just because that workflow's what you should be using on a desktop too.)
(It lets you login to GitHub in a popup browser window and then manages the access token for you. Stores the access token in a machine credential cache for subsequent calls on that machine.)
This should be a per repository setting. Not system wide! If someone has a "threat model" where "passwords are bad" then fine. Force users interacting with that particular repository to deal with this security theater of making tokens which have the same power as the account that authorized them. I guess they have better granularity, but in practice anything more complicated that Unix permissions is a total disaster and just leads to people not understanding what the different levels actually mean.
It shouldn't be imposed top-down on every user.
It's easy to forget that not every use case is a regular developer who has their dev environment set up. That said, for me it wasn't a big deal just switching to ssh keys like with my main account.
What is the correct way to automatically use when pull/pushing?
human typable one time passwords for this purpose could be cool. although it's a pretty rare use case.
Because most people want to keep it simple.
Though from a developer POV I can certainly see why passwords are so attractive: take a word, hash it, compare hash on subsequent logins.
The alternatives are tricky, but not I suspect impossible, to do in a decentralised manner. I've often pondered that something like PGP servers with revocation certificates, but adapted to logins would be near the realm of a solution.
I'm certain such a person uses TCP/IP every day and doesn't need it explained. Yet twenty years ago, some knowledge of IP addresses and subnet masks etc was necessary to get connected.
I think what prevents wider adoption of WebAuthn is the fear that users are going to lose their phone and not have a backup authenticator. But, people probably lose their phone less often than they forget passwords, so I doubt it changes the support burden much.
For the user this is extremely simple. For the programmers it's a bunch of new stuff to learn (or a new library to pull in) when implementing it, including things like you're going to want a whole new RDBMS table not just a wider "password" in the database - but for the user it's very simple and impossible to get wrong.
I implemented it by hand for my vanity site, it was not a tremendous amount of work. GitHub - since they are the topic after all - offers it today. But beyond big hitters (e.g. Gmail, Facebook) I am disappointed by how few have bothered.
It's a night and day difference in terms of security and in terms of ease of use but it seems most places aren't interested in doing more than the very bare minimum.
Passwords have security vulnerabilities, sure. But they're intuitive and usable. When you start trying to come up with alternatives there become dozens of edge-cases in which your system fails.
Or in the case of Github, you generate an SSH key and put the public key in Github and keep the private key around.
Both are much more convenient than passwords, but also more secure. It's a win/win.
They do it to prevent password reuse, but still allow passwords on the web. I don't get it
It doesn't matter how long your password is if your password is in a text file with bad chmod permissions to people who shouldn't have it.
An access token, at least, limits the blast radius.
Many, many GitHub users are not professional software developers, and many more than that are not security-minded users at all. Small incremental improvements like this are a kind of defense in depth, and it is valuable.
Do you consider password length requirements baby-sitting?