Live data from Hacker News

Git password authentication is shutting down

github.blog

301–310 of 353 posts

Re: Git password authentication is shutting down

#301

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 termina…

> "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 -…

Curious, in these three hours did you teach your student about git log, checkout $HASH, bisect, revert or any of the other ways that git is actually useful beyond being a glorified FTP ?

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.

Re: Git password authentication is shutting down

#302
post #260

Earlier quoted context omitted.

Why do you think using a GUI will make it more likely to fuck up your repo than a using the CLI? Most git GUIs are actually better at warning you that you might be about to do something stupid and making the consequences of you actions more visually clear.

I don't think it does. I've observed it many times. The GUIs don't understand git, have shitty defaults, resulting in unnecessary conflicts and histories which are essentially unreadable (Merge branch 'master' of ... x1000). If any error pops up, it is not read (not their fault - NOBODY reads error message boxes, everyone selects the default action within a fraction of a second), if there is a conflict, they usually…

This is the same debate as whenever some abstraction layer hides details - high-level vs low-level code, automatic vs manual in a car, coffee pods vs brewing machines, hand-tools vs power-tools, ready-made sauces vs make-from-scratch.

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.

Re: Git password authentication is shutting down

#303

Earlier quoted context omitted.

> What do you expect? That people without prior knowledge or experience just pick up source control in seconds? 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 so…

I get the argument but I disagree. Git is meant for software developers on projects complex enough to warrant using SCM. Using SCM for teaching development to newbies is already adding unnecessary complexity (even in a collaborative setting, flows are complex enough to distract from more fundamental topics). If you're a software developer getting to the point where using git is needed you should absolutely know the c…

> Git is meant for software developers on projects complex enough to warrant using SCM.

I and most developers I know use git or similar for projects of any size, often even if it's "just" a single file or a "one-off" change (because it rarely stays that way).

I would have agreed in the days when Subversion was the closest you could get to "easy version control" but these days in my eyes "the point where using git is needed" is not far from the point where you start making changes to an existing file.

Re: Git password authentication is shutting down

#304

Earlier quoted context omitted.

> "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 -…

> "Can you imagine? Learning to program a computer took us some hours!" 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…

For contrast, Microsoft Word and similar tools have a built-in permanent edit history. Using them requires no more than knowing what menu to find it in. As far as I know it doesn't do branching but for the baseline MVP of "I need to know what this file looked like before we made these changes" it solves the problem with significantly less than "some hours" of training.

Re: Git password authentication is shutting down

#305
post #260

Earlier quoted context omitted.

Why do you think using a GUI will make it more likely to fuck up your repo than a using the CLI? Most git GUIs are actually better at warning you that you might be about to do something stupid and making the consequences of you actions more visually clear.

I don't think it does. I've observed it many times. The GUIs don't understand git, have shitty defaults, resulting in unnecessary conflicts and histories which are essentially unreadable (Merge branch 'master' of ... x1000). If any error pops up, it is not read (not their fault - NOBODY reads error message boxes, everyone selects the default action within a fraction of a second), if there is a conflict, they usually…

In general I agree with you that Git GUI clients aren't great, but there is at least one exception.

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.

Re: Git password authentication is shutting down

#306
post #241

Earlier quoted context omitted.

You're right. A subject being difficult to master means we should do everything we can to make it difficult to learn too.

> "You're right. A subject being difficult to master means we should do everything we can to make it difficult to learn too." 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…

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

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

Re: Git password authentication is shutting down

#308

Earlier quoted context omitted.

I get the argument but I disagree. Git is meant for software developers on projects complex enough to warrant using SCM. Using SCM for teaching development to newbies is already adding unnecessary complexity (even in a collaborative setting, flows are complex enough to distract from more fundamental topics). If you're a software developer getting to the point where using git is needed you should absolutely know the c…

> Git is meant for software developers on projects complex enough to warrant using SCM. There is no such thing as a project not complex enough to warrant a SCM/VCS. There's probably an argument that there is a case where a D VCS is unnecessary, but if you aren't actually doing distributed work there's no reason you need to be aware of more complexity in a DVCS than a non-D VCS.

> There is no such thing as a project not complex enough to warrant a SCM/VCS.

I have a program I wrote that helps me straighten scanned images in bulk. It took maybe an hour to write because I did it in D and was not familiar with the language. Though I have used it for years now and made a few tweaks I have never felt the need to have it in any kind of source control.

Re: Git password authentication is shutting down

#309
post #303

Earlier quoted context omitted.

I get the argument but I disagree. Git is meant for software developers on projects complex enough to warrant using SCM. Using SCM for teaching development to newbies is already adding unnecessary complexity (even in a collaborative setting, flows are complex enough to distract from more fundamental topics). If you're a software developer getting to the point where using git is needed you should absolutely know the c…

> Git is meant for software developers on projects complex enough to warrant using SCM. I and most developers I know use git or similar for projects of any size, often even if it's "just" a single file or a "one-off" change (because it rarely stays that way). I would have agreed in the days when Subversion was the closest you could get to "easy version control" but these days in my eyes "the point where using git is…

I think this way overestimates the value of both Git and source control in general for a lot of projects. Is this the result of the now common development methodology of using as many dependencies as possible or something?

Re: Git password authentication is shutting down

#310

This is a good thing, but I've got an awkward "chicken and egg" situation. My dotfiles are stored on GitHub, which I pull using username/password. The scripts then sets up and adds a new SSH key to GitHub.

You can still use a PAT (personal access token) to authenticate via HTTPS. Instead of sending username and password, you send username and the PAT token for authentication
Post reply on HN