-
Notifications
You must be signed in to change notification settings - Fork 59.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Patch for #34710, improving caching credentials with oauth mention #34712
Conversation
Adding section about other Git credential helpers, and mention OAuth. This is based on my difficulties understanding how to get OAuth authentication from my local Git installation. The current content does not mention OAuth, or the need for organisation approval of OAuth apps not pre-approved by GitHub. Both those omissions caused obstacles for me. This is the content I wished I had at the time.
Formatting changes to correct lint problems. Label a code fence as text. Remove docs.github.com from links to docs. Delete a traling space. Turn a long sentence with two inline links into a 2-item list. This responds in part to "Writing for translation" style instructions.
Automatically generated comment ℹ️This comment is automatically generated and will be overwritten every time changes are committed to this branch. The table contains an overview of files in the Content directory changesYou may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.
fpt: Free, Pro, Team |
Removed spurious left square bracket in line 116, to attempt a fix to lint problem "MD029, ol-prefix Ordered list item prefix". Shortened line 126, a text error message. It is now 64 characters. Still longer than the desired 60 characters, but I don't see how to make it 4 characters shorter and still keep the example understandable. So, I expect it will still get a lint warning. Links on lines 115 and 116 are unchanged. The link checker seems to have a problem with them, and I don't know how to fix it.
Fix a lint problem in line 116. Change number of second item in the ordered list from "2" to "1". I am guessing that every item in the list should be numbered "1".
I would like help diagnosing these check-links errors:
The source text from caching-your-github-credentials-in-git.md?plain=1#L115-L116 is: 1. You must request that organization's approval for OAuth access by your helper. See "[AUTOTITLE](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/requesting-organization-approval-for-oauth-apps)".
1. The organization must approve access. See "[AUTOTITLE](/organizations/managing-oauth-access-to-your-organizations-data/approving-oauth-apps-for-your-organization)". The public URLs of the articles to which I want to link are:
I understand from another link checker run that I should not include the I don't understand the correct way to express those links in this article. I would appreciate guidance. The output from test-changed-content looks to me like a consequence of the same link problem. The error message says, "Error: Unable to find Page by…" and gives the same link paths. |
Interestingly, the fpt and ghec previews listed above have correct links to the GitHub articles in question. The ghes previews all give me error messages, however. |
Thanks for opening a pull request! We've triaged this issue for technical review by a subject matter expert 👀 |
@JDLH Thanks so much for opening a PR! I'll get this triaged for review ✨ |
OAuth credential helpers will get you immediate access to your own repos. If you work with repos controlled by an organization, or with your forks and clones of those repos, then two extra steps are necessary. | ||
|
||
1. You must request that organization's approval for OAuth access by your helper. See "[AUTOTITLE](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/requesting-organization-approval-for-oauth-apps)". | ||
1. The organization must approve access. See "[AUTOTITLE](/organizations/managing-oauth-access-to-your-organizations-data/approving-oauth-apps-for-your-organization)". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @JDLH — the inclusion of any links to articles such as this one, which is not versioned for GHES, in an article that is versioned for GHES, will cause link errors.
We'd look at fixing these once an SME has looked at the content you're proposing.
Many thanks
@Jaswanthgowda when you say, "Please check the settings of my account", I don't know how your request relates to this pull request. This is about improving the GitHub documentation. If you are new to GitHub and want help, perhaps try GitHub's "Get started" instructions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wanting to chime in as one of the engineers on the GitHub CLI but also as a former services engineer, I'm somewhat concerned with the suggested documentation and language changes because they could be misleading to certain readers with regard to how these various tools are used by git
and what GitHub supports.
Users configure git
to use the GitHub CLI, GCM, or whatever tool they desire as a credential helper. When git
is invoked and needs credentials, it will call whatever tools is configured to provide a relevant credential.
For example, here is git
configured to call gh
for a credential when needed when working with a git
remote for github.com
:
credential.https://github.com.helper=
credential.https://github.com.helper=!/opt/homebrew/bin/gh auth git-credential
cc: @nguyenalex836
@@ -7,7 +7,7 @@ redirect_from: | |||
- /github/using-git/caching-your-github-credentials-in-git | |||
- /github/getting-started-with-github/caching-your-github-credentials-in-git | |||
- /github/getting-started-with-github/getting-started-with-git/caching-your-github-credentials-in-git | |||
intro: 'If you''re [cloning {% data variables.product.product_name %} repositories using HTTPS](/github/getting-started-with-github/about-remote-repositories), we recommend you use {% data variables.product.prodname_cli %} or Git Credential Manager (GCM) to remember your credentials.' | |||
intro: 'If you''re [cloning {% data variables.product.product_name %} repositories using HTTPS](/github/getting-started-with-github/about-remote-repositories), we recommend you use {% data variables.product.prodname_cli %} or a Git credential helper to authenticate and to remember your credentials.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hesitate making this any generic git
credential manager as GitHub specifically supports GCM, which is the specific recommendation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest that the docs should describe both what is possible, and what is recommended. The previous wording suggests that GCM is the only possible credential helper usable. I think that is inaccurate; clearly GitHub has a way of allowing other OAuth-based credential helpers. My wording suggestion is focussed on being more inclusive about what is possible. Maybe add a sentence about what is recommended (though the later paragraphs talk about that).
@@ -23,7 +23,7 @@ shortTitle: Caching credentials | |||
|
|||
## {% data variables.product.prodname_cli %} | |||
|
|||
{% data variables.product.prodname_cli %} will automatically store your Git credentials for you when you choose `HTTPS` as your preferred protocol for Git operations and answer "yes" to the prompt asking if you would like to authenticate to Git with your {% data variables.product.product_name %} credentials. | |||
{% data variables.product.prodname_cli %} works cooperatively with Git on your command line. It helps you log in to {% data variables.product.product_name %}, and automatically stores your Git credentials for you. Choose `HTTPS` as your preferred protocol for Git operations and answer "yes" to the prompt asking if you would like to authenticate to Git with your {% data variables.product.product_name %} credentials. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, users can configure git
to leverage the GitHub CLI as a credential manager, retrieving the OAuth token stored within the OS-specific secret manager whenever git
is called via gh
commands.
I hesitate with this language because it is somewhat misleading and technically the credential being stored isn't solely or primarily for working with git
but working with GitHub. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the wording "store your Git credentials for you" is in the current docs. If this is misleading, and should instead read, "store your GitHub credentials for you", or "GitHub OAuth token" if you prefer, then that is something to consider fixing in the current docs independent of this PR.
@@ -34,7 +34,7 @@ For more information about authenticating with {% data variables.product.prodnam | |||
|
|||
## Git Credential Manager | |||
|
|||
[Git Credential Manager](https://github.com/GitCredentialManager/git-credential-manager) (GCM) is another way to store your credentials securely and connect to GitHub over HTTPS. With GCM, you don't have to manually [create and store a {% data variables.product.pat_generic %}](/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens), as GCM manages authentication on your behalf, including 2FA (two-factor authentication). | |||
[Git Credential Manager](https://github.com/GitCredentialManager/git-credential-manager) (GCM) extends your Git installation. On Git's behalf, it helps you log in to {% data variables.product.product_name %}, including 2FA (two-factor authentication), and stores your credentials securely. Or, if you have manually [created and stored a {% data variables.product.pat_generic %}](/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens), GCM can store that token securely, and provided it to {% data variables.product.product_name %} automatically when needed. In Git terms, GCM is an [OAuth credential helper](https://git-scm.com/docs/gitcredentials). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, I think the language here is a little misleading:
- GCM is a
git
credential manager that can be used with GitHub or othergit
platforms - Because of this, GCM isn't storing OAuth credentials, but storing credentials used with
git
- The "GCM can store that token securely" implies or infers that users could insecurely store credentials in GCM, which I don't know is true and might be misleading
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the thing that's tripping up around OAuth is that gh
and gcm
can both act as oauth credential helpers. Andy's right that the credential helpers store whatever credential is used to authenticate git. Optionally, some credential helpers can perform an OAuth flow for you to obtain a token so that you don't need to create one yourself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The topic of this part of the docs is Caching your GitHub credentials in Git, as part of Getting started with Git. I think the existing docs don't explain well enough the three points @andyfeller lists about how credentials, GitHub, and git interact. They instead tell users how to set up one mechanism works.
Both explaining and instructing "how to" are valid goals for documentation, but they are not the same thing. See the Diátaxis framework for what I think is a pretty good explanation of the difference.
The purpose of my PR was essentially to improve the explanation aspect of this page of the docs. I sense that the pushback relates to keeping this page a "how to". GitHub should make a choice about what the goal of this page is.
@@ -105,3 +105,25 @@ For more options for storing your credentials on Linux, see [Credential Storage] | |||
<br> | |||
|
|||
For more information or to report issues with GCM, see the official GCM docs at "[Git Credential Manager](https://github.com/GitCredentialManager/git-credential-manager)." | |||
|
|||
## Other Git credential helpers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot speak for this section here but I hesitate whether GitHub officially supports these other git
credential helpers. Again, the 2 main credential helps I've seen supported are the GitHub CLI and GCM. I don't think GitHub needs to be an authority on all git
credential helpers nor do I think we support everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andyfeller, it is certainly helpful for GitHub to define which helpers are recommended. I argue that it is important for this page to be clear about whether other credential helpers are allowed.
The fact that GitHub has a mechanism for detecting OAuth apps other than GitHub CLI and GCM, and docs on Approving OAuth apps for your organization, gives me the message that other credential helpers are allowed. If they are allowed, then I think the docs should say that somewhere, rather than be silent.
@JDLH Thank you again for opening this PR, and raising a flag on this topic! ✨ We agree the need for clarity in this portion of the docs, but given all the nuances on this topic, we'll need to handle this internally 💛 If you're looking for another issue to pick up, take a look at our help wanted section to find open issues you can work on ✨ |
This comment was marked as spam.
This comment was marked as spam.
@nguyenalex836 thank you for considering this PR, and I understand that GitHub will want to consider this part of the docs internally rather than building off this PR. Fair enough. However, I will take the liberty of adding some closing replies. I hope they will help you as you improve the docs internally. @andyfeller thank you for the review. I see your points. Some of them seem to refer to pre-existing content in the docs, rather than my proposed changes. Also, there are places where I think GitHub could be clearer about the difference between, "this is what GitHub recommends" and "this is the only thing GitHub will allow". I have added replies where I think this is the case. |
Why:
Closes: #34710
This is based on my difficulties understanding how to get OAuth authentication from my local Git installation. The current content does not mention OAuth, or the need for organisation approval of OAuth apps not pre-approved by GitHub. Both those omissions caused obstacles for me. This is the content I wished I had at the time.
What's being changed (if available, include any code snippets, screenshots, or gifs):
Adding section about other Git credential helpers, and mention OAuth. Add a few words putting GitHub CLI and GCM in relationship to the local Git installation.
I had an earlier version of this PR, #34711 , but I inadvertently closed it. Oops. This replaces that PR. It also addresses some lint problems.
Check off the following:
I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).
data
directory.For content changes, I have completed the self-review checklist.