It should support auto login for push
computerphilosopher opened this issue · comments
Is your feature request related to a problem? Please describe.
When I use git command, I don't have to type the user name and password everytime for push. Because I saved my password by credential helper.
Describe the solution you'd like
If the user is using a credential helper feature, the gitui should not ask a user name and password
I suggest using a ssh key to solve that:
- more secure
- more convenient
GitHub recommends HTTPS instead of SSH:
https://docs.github.com/en/get-started/quickstart/set-up-git#next-steps-authenticating-with-github-from-git
Note: I'm not saying HTTPS is better, just stating that currently it can't be easily dismissed as SSH is not the defacto or superior solution right now
it can't be easily dismissed as SSH is not the defacto or superior solution right now
I am not dismissing HTTPS, just my personal suggestion.
speaking of which, it seems GitHub changed their recommendation a few times: https://stackoverflow.com/questions/11041729/why-does-github-recommend-https-over-ssh
Yes, I was laughing at that when tried to collect info on this topic. I'm sorry if I implied you already dismissed the idea, it wasn't my intention. I totally agree with your personal suggestion.
My personal preference is SSH as well but I have to work with HTTPS-only repos too.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
No, not stale bot! My least favorite thing about GitHub. People not talking about a bug is better than people spamming low-effort comments. Just because people aren't talking about a bug doesn't mean they have stopped caring about it. Just because the people who care about the bug lack the coding chops to fix it doesn't mean it should be closed. Please delete stale bot.
It's interesting, this bug has made me switch entirely to SSH keys for git, which apparently brings me in line with extrawurst's opinions on HTTPS vs. SSH, but I think leaving this bug unfixed would not be a very nice way of winning that debate. If people prefer HTTPS for whatever reason, gitui should support that relatively common workflow.
@skyfaller the thing is: as long as no one picks this up it will not happen. and it being dormant that long is a good indicator no one cares enough about it. I certainly will not have time to fix it in the foreseeable future. and closed is not deleted the info is still here to point to for future reference
But my understanding of "closed" on a bug is that
- the problem has been fixed, or
- the problem cannot be fixed (e.g. upstream bug), or
- the maintainer does not want it to be fixed
If stale bot runs around closing bugs willy nilly, now the closed state doesn't mean much of anything. The difference between a closed bug and an open bug can just be happenstance, or the confluence of tangential factors such as:
- Was the nature of the bug obvious? How much discussion was required before everyone understood it? Longer discussions mean more time before stale bot triggers. I think obvious bugs may sometimes be higher priority to fix.
- How many annoying users who like to complain did this issue affect? This gives incentives to users who care about the bug to be whiny, rather than wait patiently. It also fills my GitHub notifications with stale bot and people defending against stale bot, which now that I think about it may be the core of my grudge against stale bot. I certainly comment on any stale botted issue I follow, purely because I hate stale bot, but this is a little like emailing a large email thread asking to be removed because you're getting too many email notifications. Now we all must suffer.
- Did the person with the time and energy to fix it show up in 3 months or 6 months? This is an arbitrary matter of timing, and says nothing about the bug itself.
In my last confrontation with stale bot, me and the other user who cared about the bug eventually found someone to work on fixing it... But the bug is still closed! yuin/goldmark#180 "Closed" doesn't even mean that the bug is inactive, that nobody is working on it, because stale bot sucks meaning out of the universe!
Anyway, sorry for hijacking the discussion on this issue to make it less stale, I can open a bug requesting the demise of stale bot instead ;-)
Support for git credential helpers will be a useful addition to an already very useful tool. From what I can imagine, the git config credential.helper command will indicate which credential helper is set up (e.g. https://github.com/Luzifer/git-credential-vault), and then the relevant input could be piped to the helper. I'm not sure how this would work with built-in helpers (store and cache).
@computerphilosopher credential.helper should actually be honoured. can you share your configuration as an example so I can try to reproduce it?
update:
seems libgit2 users need to call git credential fill manually: libgit2/libgit2#4873
would be great if you could build from source off of branch creds-helper-800 see #1091 - it should honour built-in store credential helper now. it expects the credentials to be set already though.
essentially if you can retrieve your credentials via printf "protocol=https\nhost=github.com\n" | git credential-store get then gitui should be able to as swell.
I have tried the branch and build it - installation was successfull, but the git credential integration does not work...
The command from the discussion
printf "protocol=https\nhost=github.com\n" | git credential fill
works perfectly.
The mentioned command here in the merge request
printf "protocol=https\nhost=github.com\n" | git credential-store get
does not work on my machine.
When using gitui I see following output in the log ( bat $HOME/Library/Caches/gitui/gitui.log)
@jgoldhammer can you check if printf ... | git credential-osxkeychain get works? (you were on macOS right?)
Yes, I am on macos...
This call works for known and unknown credentials - the script always returns.
printf "protocol=https\nhost=github.com\n" | git credential-osxkeychain get
printf "protocol=https\nhost=github1.com\n" | git credential-osxkeychain get
(Please ignore the alias hint - it is printed by fish shell)
@jgoldhammer can you test something? it turns out credentials.helper should have been supported already on the main branch. can you make sure your credential helper is configured to use osxkeychain via: git config credential.helper osxkeychain inside your repo you want to test in. I need to investigate deeper
see https://github.com/rust-lang/git2-rs/blob/master/src/cred.rs#L327
I can make sure that the credential helper is configured this way, but gitui still asks for the username and password.
@jgoldhammer ok please try this PRs branch again. turns out the config lookup for the helper to use was not checking the repo config, only the system git config. now we should get it to work.
with master it should work if you set this config via git config --global credential.helper osxkeychain (in ~/.gitconfig)
if this looks good to you I would close this ticket and create a followup:
- try more ways to be able to call
git credential fill, cause that would not require any such explicit helper to be set
Master works perfectly after setting the credential helper globally with the above command!
Thanks for making it possible 🥳
@jgoldhammer ok please try this PRs branch again. turns out the config lookup for the helper to use was not checking the repo config, only the system git config. now we should get it to work.
with master it should work if you set this config via
git config --global credential.helper osxkeychain(in~/.gitconfig)if this looks good to you I would close this ticket and create a followup:
- try more ways to be able to call
git credential fill, cause that would not require any such explicit helper to be set
I ran into the same problem, that is that credential helpers are configured via built-in configuration that differs depending on the platform which makes custom configuration of these necessary - something I thought should be avoidable.
gitoxide has two solutions for this. The first probably isn't viable for this project as it simply calls the actual git credential program which will automatically pick up the special configuration of the git installation.
The second solution is to run the git binaryto extract the special configuration path and place it first into the list of loaded configuration files. If that is possible with libgit2, I think a version of the linked code could help here, too, to make everything work without requiring to configure anything, on any platform.