Skip to content
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

It should support auto login for push #800

Closed
computerphilosopher opened this issue Jun 30, 2021 · 20 comments · Fixed by #1091
Closed

It should support auto login for push #800

computerphilosopher opened this issue Jun 30, 2021 · 20 comments · Fixed by #1091
Labels
enhancement New feature or request
Milestone

Comments

@computerphilosopher
Copy link

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

@extrawurst
Copy link
Owner

@alippai
Copy link

alippai commented Jul 1, 2021

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

@extrawurst
Copy link
Owner

extrawurst commented Jul 1, 2021

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

@extrawurst extrawurst added the enhancement New feature or request label Jul 1, 2021
@alippai
Copy link

alippai commented Jul 1, 2021

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.

@tmpgnh
Copy link

tmpgnh commented Jul 2, 2021

My personal preference is SSH as well but I have to work with HTTPS-only repos too.

@stale
Copy link

stale bot commented Oct 1, 2021

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.

@stale stale bot added the dormant Marked by stale bot on close label Oct 1, 2021
@skyfaller
Copy link

skyfaller commented Oct 1, 2021

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.

@stale stale bot removed the dormant Marked by stale bot on close label Oct 1, 2021
@extrawurst
Copy link
Owner

@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

@skyfaller
Copy link

skyfaller commented Oct 1, 2021

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 ;-)

@W1M0R
Copy link

W1M0R commented Nov 26, 2021

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

@extrawurst
Copy link
Owner

extrawurst commented Jan 22, 2022

@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

@extrawurst extrawurst added this to the v0.20 milestone Jan 22, 2022
@extrawurst
Copy link
Owner

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.

@jgoldhammer
Copy link

jgoldhammer commented Jan 23, 2022

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.

image

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

When using gitui I see following output in the log ( bat $HOME/Library/Caches/gitui/gitui.log)

image

@extrawurst
Copy link
Owner

@jgoldhammer can you check if printf ... | git credential-osxkeychain get works? (you were on macOS right?)

@jgoldhammer
Copy link

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

image

printf "protocol=https\nhost=github1.com\n" | git credential-osxkeychain get

image

(Please ignore the alias hint - it is printed by fish shell)

@extrawurst
Copy link
Owner

extrawurst commented Jan 23, 2022

@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

@jgoldhammer
Copy link

I can make sure that the credential helper is configured this way, but gitui still asks for the username and password.

@extrawurst
Copy link
Owner

@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

@jgoldhammer
Copy link

Master works perfectly after setting the credential helper globally with the above command!

Thanks for making it possible 🥳

@Byron
Copy link

Byron commented Sep 18, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants