Open alensiljak opened 2 years ago
I think it would generally make sense to see if credential.helper
is set and if so, use that to authenticate, making the current hardcoded options a fallback
@Murmele does this sound good to you?
Yes of course makes sense instead of hardcoded
FYI, by checking this topic, I've found a keepassxc credentials provider for git (https://github.com/Frederick888/git-credential-keepassxc) and thought it might be worth sharing for those who use KeePass and git. Hence, relying on existing external credentials providers would help immensely by offloading that part to specialized components completely.
I would like to work on this, if its not currently taken.
@H-4ND-H you can work on it. I can assign it to you, so it is saved for you
@Murmele Is there any document for project coding style, I see some inconsistent naming here and there regarding naming private vars i.e mVar
or m_var
I want to follow the project standard.
@H-4ND-H I am using mostly mVar, but I am not sure if everybody is doing it. At least it will not be complained about. It is the same for single line ifs. I used most of the time without brackets, but of @exactly-one-kas pointed to an apple issue where this leaded to problems. @exactly-one-kas do you have any recommandations. The problem I see is that we need then also an automatic check. But I don't see any issues if the codestyle is not completely aligned
Personally, I'd just lose the prefix, since there's also no prefix for private methods or protected members
Automatic checks for that would probably be overkill since m
as a prefix has valid uses. But I'd be in favor of making all variable names consistent (but that would be a metric fuckton of work with little impact, so we probably won't do it 🙈)
Yes I think so. The m prefix is perfect, because then in an IDE the automatic proposals are working great, but forcing it is really an overkill. I checked the latest merge requests and there mVar
is used, also the rest of the code uses it mostly. So I think you should go with this convention
Hope u guys doing well, I was busy last week, so here is my take on this issue,
The problem with constant prompt for credentials is that Gittyup checks for availability of a store, rather than checking if git is using that particular store in credential.helper
. So for example on my system I have libsecret
but I use store
as my git store, but the code selects libsecret
just because it is available. Gittyup also tries to use store by a flag set in static config files(.lua) and not what is set on global git config file. Furthermore it does not alter global git config when user checks/unchecks the checkbox asking if it shall store credentials.
So I believe we shall alter the code this way:
credential.helper
in global git config to determine if we shall use a store and which store to use.helper = store
comobox
to repo config editor, with a list of available stores name's, so that user can change the store in use.I will push a code for review in a day or two.
This issue should be considered critical, it is almost impossible to use app with external credential helper.
Will this get fixed? Seems annoying that the credentials are asked while it's already authenticated (works in Terminal)
I see a PR is merged for this issue, however I am still facing this issue quite often and it really bothers the user experience.
My ~/.gitconfig
looks like:
[user]
email = my@email.com
name = My Name
[credential]
helper = manager-core
And I am using version 1.3.0
on MacOS.
I'm using a Git repository hosted on Azure. The Git CLI uses Git Credential Manager to authenticate using MFA. This makes fetch/pull/push operations succeed in the terminal.
Trying to fetch in Gittyup, the credentials window pops up every time a remote operation is attempted. Could this somehow recognize the credential manager that is set up in the Git global configuration (
git config --global credential.helper manager-core
)?The Credential Manager also allows GitHub to work with MFA enabled.