Git Extensions is a great tool but the credential management is very weak #4916
Comments
|
Hello, I know that this is not an answer but it may help you until the problem is properly solved. I usually use ssh keys or tokens to make possible the authentication of the git without using the credential manager. |
|
Thank you for kind words. Without knowing under what circumstances you are having troubles it is hard to provide a specific advice. Have you searched for similar issues and possible resolutions? https://github.com/gitextensions/gitextensions/search?q=wincred&type=Issues There are few things you can do:
|
|
Thank you for responding.
The specific circumstances are as follows:
When you go through the installation there are a number of choices to make, but it is impossible to choose the right options because there is no way to know how these choices will affect your user experience.
In our office different people chose different options more or less randomly because they have no idea what effect these choices will have on the software.
Now we have some people with a terrible user experience, others with a very good user experience and some half way between.
Most people just want an install that installs the software in a way that works. If you want to support other installation scenarios for people that understand what all these pieces are and how they fit together then this should be some kind of “advanced” mode.
At the very least the default values should result in a working and usable installation.
… On May 3, 2018, at 3:12 PM, RussKie ***@***.***> wrote:
Thank you for kind words.
Without knowing under what circumstances you are having troubles it is hard to provide a specific advice. Have you searched for similar issues and possible resolutions? https://github.com/gitextensions/gitextensions/search?q=wincred&type=Issues
There are few things you can do:
make sure you all run git 2.16+ (#4523)
make sure you have Putty 0.70+ (#4509)
use SSH instead of HTTP
If you need to use HTTP, remove all reference to git-credential-winstore.exe and replace them with wincred or manager (#3511 (comment))
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I hear you, unfortunately installation scripts are somewhat an arcane art which the core team could not master to date. We are acutely aware of issues related to the installer, however some are much harder then others. It is worth noting, some of the installations you may be referring to are in fact 3rd party installers (e.g. git installer, kdiff installer etc), which we don't own, and that are bundled in our complete installer for the convenience. The git installer has a number of configuration items for users to choose. On the topic of bundling - this is a double edge sword as we found. For example, the git's release cadence is higher then ours, and our users may be installing outdated git versions. |
|
Thank you for your response, I look forward to future releases that address this issue.
… On May 3, 2018, at 7:23 PM, RussKie ***@***.***> wrote:
I hear you, unfortunately installation scripts are somewhat an arcane art which the core team could not master to date. We are acutely aware of issues related to the installer, however some are much harder then others.
It is worth noting, some of the installations you may be referring to are in fact 3rd party installers (e.g. git installer, kdiff installer etc), which we don't own, and that are bundled in our complete installer for the convenience. The git installer has a number of configuration items for users to choose.
On the topic of bundling - this is a double edge sword as we found. For example, the git's release cadence is higher then ours, and our users may be installing outdated git versions.
In the future releases we will be unbundling 3rd party components from our installer, and those components will need to be installed by users themselves.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I am setting up a new dev environment with a different company and going through all this pain all over again. |
|
Could you please elaborate what exactly is lacking?
…On Tue, Sep 25, 2018, 2:32 PM Martin Halliday ***@***.***> wrote:
I am setting up a new dev environment with a different company and going
through all this pain all over again.
You can create the greatest software in the world, but if users can not
login/register it is all a complete waste of time.
I really like Git Extensions but accessing a remote repository is a total
nightmare.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4916 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEMyXgIuE03Ex4rjwf9cW_WeeiYkxq8rks5uebHQgaJpZM4Txe0_>
.
|
|
Ask anybody who is very familiar with computer technology in general but is not familiar with GitExtensions to try to install it and have it pull/push to a remote repository without asking for credentials each time. Stand behind the person and watch as they gradually become more and more angry and frustrated until they eventually pick up their computer and throw it out of the window, then go and get really drunk. The short answer to your question is absolutely everything is lacking. If users can not get past step 1 all of the other cool features of the software are a total waste of everyone's time who has worked on it. The multitude of options for configuring GitExtensions to talk to a remote repository create thousands of permutations most of which do not work. Finding a configuration that does work is extremely difficult and most of my co-workers have given up trying and just type the password on every remote operation. Most people do not care which specific flavor of widgit they are using, they just want to version control their files using Git. Spending weeks reading thousands of pages of documentation on dozens of tools, libraries and plugins just to get off the ground is just not feasible for most users. |
|
After several more hours this evening I got to a point where Git Bash works without prompting for a password, this seems like a good place to start. It works in both the Git Bash shell and also in the Console window within Git Extensions, but the Pull dialog still does not work. You can see all three in this screenshot. |
|
It's not that hard.
In the repo manage remotes It will automatically load that key and start the putty agent if needed. I just hit fetch all after closing the putty agent. |
Can you please be more specific? I have spend the whole evening tonight replicating a fresh install experience.
Up until this point I have not been asked for any usernames, passwords or any other keys.
Granted, setting up a SSH key for a remote repo is slightly more involved (typically I simply copy my .ssh folder across), but there are multiple guides available (e.g. the Jay's guide above, github guide, bitbucket guide). A number of engineers in my team in past few weeks had their laptops rebuilt and they had to completely reinstall their dev environments. I haven't heard a word of complaint from anyone (from a grad to a lead level). All git and GE related installations were most straight forward (compared with other tools, such as VS). At this point I am afraid I can't see anything wrong or overly complicated in settings up or working with a git repo.
Sorry, but to me it looks like you had a bad day and came here to vent. |
|
If Git works from bsh, it works from GE too.
|
|
Another thought. Use chocolatey. example choco upgrade gitextensions -y
choco upgrade p4merge -y
#any other packagesYou can also create a package that has your configuration and it depend on the needed packages. Example package: https://chocolatey.org/packages/EthanBrown.GitExtensionsConfiguration You can then either alter the gist to alter your git config and/or gitextensions settings file to have whatever settings you desire or have the package start you off with your default config. With the gist, you can control what settings get set on run of the script. |
|
It is true that I am having a bad day as a result of this but I am not here to vent. If a whole team of developers tried and not one person succeeded, I think the statement that "Its not that hard" are clearly incorrect. More accurately, it's not that hard if you understand exactly how all of these pieces work and how they fit together. I think that the walkthrough by @vbjay above goes a long way to solving the problem, so thank you for that. |
In response to above: It is your responsibility to learn git and how it works. We expect some understanding of git to use this program. It is not a gui to allow monkeys to create Hamlet. Glad the walkthrough helped. The other point is that you can post a detailed issue and ask for help and read the documentation.
|
|
Hello, I will speak from the point of just a user and my experience with this. All of the above its my opinion and im not anywhere near related to the main contributor team and the Owners. So please before judge my comment and say anything bad know that. Thanks. |
|
From my original post:
The walkthrough by @vbjay above is the documentation that I feel was missing. I hope this helps other people to get the most out of GitExtensions. |
|
… On Tue, Sep 25, 2018 at 2:50 PM Martin Halliday ***@***.***> wrote:
From my original post:
In general Git Extensions is a really great tool and we really appreciate
the effort that went into creating it, but the area of credential
management is very fragmented and confusing. Even a document with steps to
configure an existing install to remember credentials would solve this
problem.
The walkthrough by @vbjay <https://github.com/vbjay> above is the
documentation that I feel was missing. I hope this helps other people to
get the most out of GitExtensions.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4916 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADdhsUwHtpLoPVrUzgw7i6BL-Yn6oUDlks5uenr9gaJpZM4Txe0_>
.
|
|
Thank you, Jay.
If I may suggest, the problem should be address by educating engineers. Brownbags and tech walk throughs typically help. That's how we teach and upskill our engineers. Is there something outstanding on this issue you would like addressed, or can we close it? |
|
I agree that GitExtensions is a giant mess and has the usability of a potato. Everything is so overly complicated and has way too many options and dialogs. If you want to see how GIT could work for most people, just take a look at Abstract (its basically Github for Sketch files). Its so simple and works with almost 0 explanation. We here are also Developers and it took us half a day to get GitExtensions up and running without having to enter a password. The whole SSH, putty, etc. thing is just ridicolous. |
This comment has been minimized.
This comment has been minimized.
|
@seltzdesign what did you hope to achieve with your comments here? We are volunteers and our output is proportional to our motivation. Taking a 💩 on the project isn't helpful. If I assume you were trying to help, then perhaps you could open specific issues with things we could address, or even roll up your sleeves and help improve things. Each git client has its own strengths and weaknesses. If GE is not for you, that's fine.
I use OpenSSH and never have to enter a password anywhere. I don't know if other maintainers use Putty. It sounds like there is something we can do to improve things in this space. It'd be useful if you explained more about what makes it "ridicolous". |
|
I use putty. I generated a key with a password so no one but me can push as me. Once I enter the key password, I can push as long as the the key agent is running. I can kill it when I choose. I stored the key in google drive so that it travels wherever I go. Yes. I know you're not supposed to share it like that. I do have a good password on it. Putty makes it dirt simple. Generate key. Use this to set up the github or whatever user account Tell remote to use ssh key
If the key agent isn't running it will start and ask you for your password for the key if the key has a password. I for one think we did a great job with the putty side of things. The only thing I want to do is embed chocolatey and get rid of the putty binaries so that user installed version stays current. I want people to install our program and our program to run chocolatey to make sure putty and git are installed. I want it to tell them there are upgrades for the packages we follow. I want portable users to be able to extract our program and it deploys git and putty using chocolatey to a dependencies folder where GE is located. That is my goal for the future of GE. |
|
Thanks @vbjay, I've not seen the Putty workflow before. For completeness, here's the OpenSSH approach. It's all command line (and from memory, so I'm missing output): Copy the text there and paste it into GitHub/Bitbucket/Azure DevOps/wherever.
I create a different key pair per device. That way if I lose a device, I can just pull that one key from online services and carry on with other devices. Setting up SSH might be annoying for new git users, but it's a one time thing per machine and things are completely seemless afterwards. |
|
@Mike-EEE |
|
I was having trouble with the same issue when pushing through Visual Studio 2019. Just so it's clear re: Mike-EEE's message. After signing in in with your normal user / password in Visual Studio, you have to go edit the credential in windows for git/visual studio and use your personal access token. |
|
Wanted to share my solution as well. I have 2 keys: My RSA key is for (manual) SSH connections, while I use my ed25519 key for GitLab. I had set Git Extensions to use the ed25519 key according to vbjay's instructions, but kept getting Errors like I checked that both Keys were loaded into pageant (they were) and that the Remote was using the correct one. Still no dice. Eventually i noticed that the problem was not even within Git Extensions: PuTTY's "Default Settings" were configured to use the RSA key, preventing Git Extensions from using the other one. |
|
Thank you for sharing
|
|
@Mike-EEE's solution of manually adding a Windows Credential worked for me. Type: generic, username and password, no 2FA. |
|
Caveat: the generic Windows Credential method seems to only allow one username per url so for multiple identities one needs to make the internet or network address unique. For example, a work identity:
|
|
The Windows Credential solution from a couple weeks ago doesn't quite work as described. A credential needs to be added for every organization or repo, meaning you can't have a generic |
|
Mine was simply deleting them especially the one for |
|
I needed to remove Visual Studio from here https://github.com/settings/applications |
|
What's worked for me:
|
git credential-cache exitworked for me. |
It's not the best solution, but It works, thanks. |
|
Unfortunately for me, I am using ubuntu so I can't find a solution for this |
|
Using the Gihub desktop app also seems to work without needing a PAT. |
|
Deleting all Windows Credentials related to GitHub (Visual studio, VS Code, ...) and signing again from VS Code solved for me. |
|
Anyone else dislike credential manager? my git uses my network credentials, which we have to change periodically so now I have to delete every git entry in credential manager every time my password changes. credential manager also scrolls back to top every time I remove one, so scroll back down every time. we have lots of repo's, so this is painstaking. I used to not have to do this, git extensions used to prompt me for new credentials when it couldn't authenticate. Can gitextensions go back to prompting for new credentials when it encounters an authentication issue? |
For me, that's not gitextensions that handle this but the git credential manager. A lot of things could be the reason of the behavior change and my knowledge is limited on this part but could it be a change introduced by the new Git-Credential-Manager-Core (that replaced Git-Credential-Manager)? Note: maybe that needs opening another issue to not pollute this one... |
Yeah, have no idea on that... I did try out a different git gui and it had the same issue, but it actually has it's own authentication section that looks like it simply pulls from Credential Manager. It allowed me to more quickly identify and remove repo credentials then Windows' own Credential Manager, so I used it. Not great, but better than what I was having to do. Now I will have to do this all over again the next time my password changes. Sigh. |
|
I found using a URL like |
|
I have been having the same issues and came here for a clear answer. But was immediately frustrated with comments like "it's very straight forward" and other comments to the op saying he was just here to vent. Its like wow is that how we treat fellow developers these days. You come to a forum for help and you get that type of response. Also who wants to go read a ton of documentation just to get something installed. If its that complex then the developer might think about making a tool a bit more "straight forward". |
|
For https: authentication, the easiest is to use the Git Credenitial Manager Core that comes with Git-for-Windows: For ssh authentication most Git servers have their own descriptions, a few links on the GCM page: |
|
What seems to be working best for me now is to use http and edit the remote url to include the username of the account I wish to use in front of the domain name:
|
|
At first, thank you very much for Git Extensions! I already had taken a look at it several years ago and now are coming back to it again. I can say that it has greatly evolved in every respect. Great job ... I believe that everybody who uses repositories via HTTP(S) could read the documentation which explains the Git Credential Manager. Furthermore, if somebody puts a minimal effort in own research, he will inevitably stumble across Git Credential Manager and its friends. Put short, somebody who refuses to read at least the most important part of documentation and who isn't able to do minimal research probably shouldn't be called a developer. Some more problems arise when it comes to SSH. In the newest (at the time of writing) version of the famous (and excellent - thanks again folks) Git Book, we find the following statement on page 337:
This statement is the only thing in that excellent book which IMHO is dangerous and misleading. Not every person who tries to learn Git is into security, and the advice to have an SSH key without a passphrase is more than questionable. The opposite is true: Always put a passphrase which is as strong as possible onto your SSH keys. This really needs to be clarified. Coming back to the actual issue: IMHO the problem is that every software for Windows that deals with SSH keys is using the code, libraries or tools from the putty universe. Unfortunately, Git Extensions also does this. Putty, as likeable as it was at the beginning (I have used it for several years in the 2000s), has upset me several times for two reasons:
This alone already made me stop using Putty a long time ago and use Cygwin's ssh instead.
Even people who are ready to accept Putty's own key format (which I don't) will freak out at this point after having lost several hours unsuccessfully trying to convert the OpenSSH key their admin gave to them into the Putty format. Without these two problems, SSH would be a no-brainer in Git Extensions. The integration has been done very well, and even coping with pageant is very easy. In other words, IMHO the integration is exemplary, and again, somebody who doesn't get it within an hour or so probably isn't a developer. Man, even the dialog boxes during the installation provide the choice of which SSH to use, telling clearly about each choice's consequences. But the good integration and all the explanations and help can't mitigate that Putty itself is flawed. Therefore, we are using an external ssh program (Cygwin's ssh), and this is the point where a bit more of documentation would be good, at least a few hints regarding ssh-agent and a link to its documentation, or other (Non-Cygwin) SSH implementations, like the native one from Microsoft. It is a real pain having to enter the SSH passphrase each time you fetch, push or pull, but most Windows users probably are not aware that there is a thing like ssh-agent even under Windows (and their admins or managers justifiably won't allow them to use SSH keys without passphrases). Furthermore, there is an extremely nasty bug in Git Extensions who has cost us some time yesterday, and I can imagine that some of the people who have complained above have been hit by it. I'll eventually open a separate bug report if I find out how to do that :-) Finally:
Could you please shortly elaborate on this, especially how you manage to do this in Windows and with a passphrase on every key? |
I don't use a passphrase so perhaps I'm not feeling the pain point you are. |
|
@drewnoakes That explains it :-) Thanks for the fast reply. |
and others
Everyone uses Git Extensions in our office and some people have to type their username and password every time, some people have to just type their password, and for other people their credentials are remembered. In some cases there is a console window to type into and in other cases it is a popup login box.
Everyone in our office would like Git Extensions to remember their credentials, but nobody can figure out what path you have to take through the install options to get there, or how to take an existing installation and configure it to remember the credentials. Many have tried and all have failed.
In general Git Extensions is a really great tool and we really appreciate the effort that went into creating it, but the area of credential management is very fragmented and confusing. Even a document with steps to configure an existing install to remember credentials would solve this problem.
Thanks.
Do you want to request a feature or report a bug?
What is the current behavior?
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
What is the expected behavior?
Environment you encounter the issue:
Did this work in previous version of GitExtensions (which)?
The text was updated successfully, but these errors were encountered: