We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Currently, the hub command line tool which code uses internally in some cases has its own credential storage under ~/.config/hub.
hub
code
~/.config/hub
The code gem itself stores its own set of credentials (just the oauth token) inside the global git configuration file (~/.gitconfig).
~/.gitconfig
The problem is the publish command. It first uses the API to check if there are open PRs for the current branch. Then it uses hub to create a PR.
On a fresh system, the result of that would be that the user is asked for their credentials twice, first once by the API, then once by hub.
Ideally, we would have one set of stored credentials.
If we intend to stick with using hub internally, we should be accessing hub credentials. They are stored in plaintext and easily readable.
If we intend to not rely on hub at some point, then we should somehow provide hub with the code-stored set of credentials, if that's possible.
I think the first choice (assume we will keep using hub) is prefered.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Currently, the
hub
command line tool whichcode
uses internally in some cases has its own credential storage under~/.config/hub
.The
code
gem itself stores its own set of credentials (just the oauth token) inside the global git configuration file (~/.gitconfig
).The problem is the publish command. It first uses the API to check if there are open PRs for the current branch. Then it uses hub to create a PR.
On a fresh system, the result of that would be that the user is asked for their credentials twice, first once by the API, then once by hub.
Ideally, we would have one set of stored credentials.
If we intend to stick with using hub internally, we should be accessing hub credentials. They are stored in plaintext and easily readable.
If we intend to not rely on hub at some point, then we should somehow provide hub with the code-stored set of credentials, if that's possible.
I think the first choice (assume we will keep using hub) is prefered.
The text was updated successfully, but these errors were encountered: