Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git password authentication is shutting down

github.blog

Post reply on HN
Print view View original

161–170 of 353 posts

Re: Git password authentication is shutting down

#161

Post by prepend »

javajosh wrote: post #150
prepend wrote: post #145

Earlier quoted context omitted.

I disagree. I think TFS is an abortion geared around project managers with dev features bolted on. The wiki is ok if you’ve never used other products and their optimizations require an understanding of TFS’ project management suite. I’ve never been able to teach non-TFSers how to use the wiki who don’t commit to learning TFS.

Yes, TFS is overall a survelleince produce for managers. However, that has nothing to do with the wiki implementation included with it, which is quite good. Don't throw the baby out with the bathwater.

I found it hard to use for the primary goal of a wiki: allow contributors to contribute. Wikis need diverse SMEs and it was hard to get SMEs to understand how it worked well enough to contribute and edit content, much less organize. Was able to do this with confluence, mediawiki, and tons of other wiki sites

Re: Git password authentication is shutting down

#162

Post by westurner »

BeefySwain wrote: post #39
hiimshort wrote: post #24

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…

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…

Maybe start here: http://learngitbranching.js.org/

GitHub Learning Lab: https://lab.github.com/

https://learnxinyminutes.com/docs/git/ #Further_resources

https://westurner.github.io/tools/#git

Re: Git password authentication is shutting down

#163

Post by doubleunplussed »

What's the recommended way to manage git clones on shared computers now?

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.

Re: Git password authentication is shutting down

#164

Post by efnx »

doubleunplussed wrote: post #163

What's the recommended way to manage git clones on shared computers now? 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…

You can use an access token (and not store it), or you can use one unique ssh key per machine.

But yeah, it looks like for your use case this is not a great change.

Re: Git password authentication is shutting down

#165

Post by devman0 »

doubleunplussed wrote: post #163

What's the recommended way to manage git clones on shared computers now? 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…

You can wrap an ssh key with a password.

Re: Git password authentication is shutting down

#166

Post by vtbassmatt »

voltagex_ wrote: post #142
WorldMaker wrote: post #108

Earlier quoted context omitted.

You can use a supporting Git Credential Manager (such as GCM Core: https://github.com/microsoft/Git-Credential-Manager-Core ) to keep using HTTPS and login/password. Instead of typing in your username/password directly in the CLI, it pops up GitHub's login page where you input login/password and then does the dance for you to get an access token from that. (Git for Windows default installs GCM Core. Some Linux distro…

Wait til you work in a corporate environment where core doesn't work but the original GCM does. They bungled that transition.

Have you filed an issue on it? We'd be happy to investigate. https://github.com/microsoft/Git-Credential-Manager-Core/iss...

Re: Git password authentication is shutting down

#167

Post by westurner »

jcrites wrote: post #156
DangitBobby wrote: post #149

Earlier quoted context omitted.

I actually don't want to rebase. Rebase can rewrite your local history and make it impossible for you to push without doing a force push (or some other more complicated manuevering). The only time pull with rebase is okay (on a shared branch such as master) is when you know that your local branch is strictly behind remote. That's exactly what --ff-only does. It rebases only if you are behind remote, and declines to d…

If "git pull --rebase" succeeds without reporting a merge conflict, then it's tantamount to having executed the command with "--ff-only". 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 touch…

`git pull --rebase` usually is what I need to do. To save local changes and rebase to the git remote's branch:

  # 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
HubFlow does branch merging correctly because I never can. Even when it's just me and I don't remember how I was handling tags of releases on which branch, I just reach for HubFlow now and it's pretty much good.

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 true

Re: Git password authentication is shutting down

#168

Post by Hello71 »

jcrites wrote: post #137
DangitBobby wrote: post #128

Earlier quoted context omitted.

Uh oh, you've now merged remote master into your local master which was two commits ahead and 3 behind! My git config has fast-forward only for pulls and I habitually use --ff-only for any pull :)

The command you want is "git pull --rebase". There are configuration settings to make "git pull" rebase by default, and I'd recommend always turning that on that default (which may be by why the person above omitted it from his pull command). 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 confi…

as far as i can tell there's no git --configure. you may be confusing it with Xorg -configure, which is (very) obsolete and shouldn't be used.

Re: Git password authentication is shutting down

#169

Post by sethammons »

geofft wrote: post #93
AlexandrB wrote: post #36

Earlier quoted context omitted.

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

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/inst... )" than…

You can actually detect from the server side if curl is being piped and dynamically change the payload.

Re: Git password authentication is shutting down

#170

Post by Hello71 »

jcrites wrote: post #156
DangitBobby wrote: post #149

Earlier quoted context omitted.

I actually don't want to rebase. Rebase can rewrite your local history and make it impossible for you to push without doing a force push (or some other more complicated manuevering). The only time pull with rebase is okay (on a shared branch such as master) is when you know that your local branch is strictly behind remote. That's exactly what --ff-only does. It rebases only if you are behind remote, and declines to d…

If "git pull --rebase" succeeds without reporting a merge conflict, then it's tantamount to having executed the command with "--ff-only". 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 touch…

> If "git pull --rebase" succeeds without reporting a merge conflict, then it's tantamount to having executed the command with "--ff-only".

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

Post reply on HN