HTTPS Cloning Errors and Cached Credentials

[megbird]

Issue overview

On this page:

https://help.github.com/en/github/creating-cloning-and-archiving-repositories/https-cloning-errors

...password caching is only mentioned in a tip after the "Check your permissions" section as something a user might want to start doing to add some convenience.

Actually, incorrectly cached credentials could be the source of the problem that brought them to this page in the first place.

I suggest we add a line to that section, before the line "When prompted for a username and password, make sure you use an account that has access to the repository.", saying something like "Check that your computer does not have any incorrect or out of date credentials cached that are causing authentication to fail."

Possibly also include a link to https://help.github.com/en/github/using-git/updating-credentials-from-the-osx-keychain

While we're on the subject - why don't we have a similar article to the keychain one about Windows Credential Manager? That seems a weird omission!

Here's the snippet I use when telling users to check that:

To remove any cached credentials from the Windows Credential Manager, you'll want to:

- Open the Start Menu
- Search for Credential Manager, and open it
- Find a GitHub username and password under Generic credentials, and remove them

You might also find this documentation helpful:

https://help.github.com/en/articles/caching-your-github-password-in-git

(Click for Windows version)

Products affected by this issue

to be completed by the core product docs team first responder

• Dotcom (all products)
  • GitHub Free
  • GitHub Pro
  • GitHub Team
• GitHub Enterprise Cloud
• GitHub Enterprise Server (Versions: )
• API
• Desktop

Note: The doctocat who triages this issue may invite you to open a PR to address it. Doing so is absolutely not required, though it's helpful for a speedy fix! Someone from our team will work with you to take your changes across the finish line.

/cc @github/product-docs-core

[welcome]

Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[casals]

Just a couple of observations here:

• The current Windows equivalent to git-credential-osxkeychain is Git Credential Manager Core (which also runs on macOS) - but it's optional, although it's much more feature-complete (especially considering Azure-related scenarios). Referring this also prompts for an update on the documentation for macOS users.

• This seems to be a three-pronged issue. I suggest breaking it into (i) adjusting the https cloning errors page as suggested by the author; (ii) creating a Windows Credential Manager documentation page (are there any GitHub guidelines involving different Windows versions?); and (iii) creating a documentation page (or at least a summarized reference) to Git Credential Manager Core, which also covers support for Linux users (GCM Linux support is currently in preview).

[felicitymay]

Hi @casals - your review of this issue seems spot on.

The pull request that you've raised will fix the first part of your breakdown, but will close this issue when it's merged. Would you be able to create two new issues outlining the other changes?

These seem like larger chunks of work, so it would be a good idea for people to outline their plan for the content to fix the issue before they write a new topic and raise a pull request. Within the GitHub docs team, we always write a content plan and get it reviewed by another member of the team (and any other relevant staff) before starting work. It ensures that we don't waste time heading off in the wrong direction or having missed out an important step - it also makes the review easier since the big decisions are agreed before you start writing the content.

[casals]

Would you be able to create two new issues outlining the other changes?

Hey @felicitymay - absolutely - I was just waiting for a confirmation on this analysis. I'll create the new issues right away.

Writing a content plan definitely sounds right as a first step (for both new issues, of course). Do you have an internal template/model to share? (Otherwise I can just outline the topics as meta-content for the targeted content structure).

[felicitymay]

Writing a content plan definitely sounds right as a first step (for both new issues, of course). Do you have an internal template/model to share? (Otherwise I can just outline the topics as meta-content for the targeted content structure).

@janiceilene - I know that you've thought about the process for OS contributors to work on more complex topics. What do you suggest is the best approach here?

[casals]

IMHO the best approach would be (i) to open a new issue detailing the need for a content plan (which means contextualizing it properly on README.MD or CONTRIBUTING.MD, (ii) get it approved/PR-ed (which means we'll have a central point for future collaboration/improvements), and (iii) using it to close the newly opened issues (#698 and #699).

Tackling (i) and (ii) is relatively fast (if you think this is a good plan I can probably create the issue/PR today), so there would be no real impact on addressing (iii).

[felicitymay]

👋🏻 Thanks for the summary @casals ✨

In the longer term, we plan to create clear paths for users contributing small fixes (the focus for this month), more substantial changes to existing articles, and entirely new content. We're not ready to formalize the process just yet but, if you're keen to work on the issues you've created for new content now, then we could work together on the content plan. If we keep notes of your questions - it might be a good way to identify what information open source contributors will need to have for a good experience and successful outcome. Otherwise, if you'd prefer to wait until we have published a template for a content plan, maybe you'd like to test-drive the new process when we've written it 😄

Let me know what you think.

[casals]

Sure! I'd rather work on the issues for now (just so we have a starting point) and (possibly) use the experience as input to a future content model. Since this issue is mentioned in the new ones, we have a way to not lose track of the conversation/use it in the future. After October we can just put this together with those other issues (IIRC every issue I opened was somehow related to a contributing question) and use them with a content plan (happy to help both with design and testing). 😄

[felicitymay]

That makes sense. I've dropped a comment with some ideas on the first of the issues that you opened (#698).

Rather than carrying on discussing how to start working on more complicated issues here - I wonder if it's worth starting a discussion. That way, it's easier to respond to specific comments and have more than one thread of conversation going at once.

[casals]

It makes more sense, agree. (Also, there's the risk of everything getting buried here a few months from now...)