I have my gitconfig like this:
....
[credential]
helper = !\"D:/devtools/MinGit/mingw64/gcmw/git-credential-manager.exe\"
useHttpPath = true
....
But after saving some credentials and looking into the windows-credential-manager (of the control panel) I saw the credentials are not saved with the http path component (only the url). So the config "useHttpPath = true" is ignored completely.
If I use version 1.5.0 or wincred everything works as it should.
Thanks for the report @nintendoluk . It seems my decision to rely on the NetFx System.Uri class was a mistake. I am working on reverting this poor decision and returning all broken functionality to a nominal state as quickly as possible.
I tried this using GfW 2.9.3(2), which should include your bugfixed 1.6.1 as you see here https://github.com/git-for-windows/git/releases
And useHttpPath still does not work for me :-(
@nintendoluk it seems like you're having serious issues with the GCM. None of which I can reproduce. The difference between our experience is likely the differences in our setups.
For example: I have two configurations, both on Windows 10 x64, using Git 2.9.3(2)
Both work for me, both use HTTP path just because I'm "eating my own dog food" where possible.
Can you help me setup a reproducible scenario where I can see some of the issues you're experiencing?
First of all: Thank you for your helpfullness :-)
We use the SCM-Manager (https://www.scm-manager.org/) as a Git-Repository-Server. I am pretty new to Git and dont know whats an usual setup.
When I pull from there and look into the windows credential store (control panel) the credentials are only stored for example "https://scm-manager.internalXY.com" and not like I think it should be: for example "https://scm-manager.internalXY.com/testrepository"
Thanks, this gives me an incredible amount of information to work with. First, from a GCM perspective, the https://sc-manager.internal.com/repos/my.git URL tells me that you're in the GCM's BasicAuthority path. Second, I can now look at if scm-manager does anything 'unusual' which could trip the GCM up.
Thanks.
btw. version 1.5.0 worked well, but it always asked for proxy-credentials, even if no proxy was set (thats why we wanted to use 1.6.x)
I just tried "useHttpPath" with github and it seems to work.
So it's indeed problem with the SCM-Manager ( here is their bitbucket btw. https://bitbucket.org/sdorra/scm-manager )
For us this is no issue but we wanted to use HttpPath with external gits only, anyway :-) I only tested it with our SCM-Manager ^^'
Thank you for your help!
I tried a little and now I see, the problem is not with the SCM-Manager.
When I put "useHttpPath = true" into the repositories config-file, it works perfectly fine.
It seems like, the configuration gets ignored if I put it into "D:\devtools\MinGit\mingw64\etc\gitconfig"
if useHttpPath is not set in the repositories config, it also does not work with Github
It seems like, the configuration gets ignored if I put it into "D:\devtools\MinGit\mingw64\etc\gitconfig"
if useHttpPath is not set in the repositories config, it also does not work with Github
Sounds like a bug with GCM discovering which Git.exe you're using. The GCM will discover the Git on your %PATH% and then read its gitconfig before it finds any version of MinGit.
Does this sound like it could be the source of the problem?
Have you tried placing the values into the global Git configuration file?
The GCM will discover the Git on your %PATH% and then read its gitconfig before it finds any version of MinGit.
This must be the error! I am using the portable version without installation, so my %PATH% does not include the path to the Git.exe
I will just try out tomorrow, thank you :-)
I will just try out tomorrow, thank you :-)
Great, let me know the outcome - also, PortableGit relies on the portable config file, I recommend that you rely on that if you can.
I added the following paths to %PATH% (in the windows environment variables)
_D:\devtools\MinGit_ (Git root folder)
_D:\devtools\MinGit\cmd_ (Location of Git.exe)
_D:\devtools\MinGit\mingw64\etc_ (Location of gitconfig)
But the gitconfig is still not getting used
what am I doing wrong?
@nintendoluk don't add multiple versions of Git to your %PATH%, as the first version found is the version selected. You're not winning by doing that. 馃槈 In the case of your installation of MinGit, you only need the path to 'MinGit\cmd', though I've been asking @dscho to remove '$GITINST/cmd/git.exe' as it gives the false impression that MinGit can be used from CMD.
Regardless, I highly recommend that you place your config options into the "portable" configuration. Git for Windows understands this configuration option and the config should be in a file like `C:\ProgramData\Git\config'.
Hi whoisj,
I have corrected my %PATH% as you said, and put 'MinGit\cmd' at the front (so it should get used).
But the config-file located in MinGit\mingw64\etc\gitconfig is still not used by your credential manager.
But it is the standard config file of MinGit/Portable-Git and it is definitely used by git but everything credential-manager related does not take effect.
I think your credential manager cant locate the config file, because the folder-structure for MinGit is different as the folder-structure of the "usual" git.
best regards
Lukas
I've been asking @dscho to remove '$GITINST/cmd/git.exe' as it gives the false impression that MinGit can be used from CMD.
Sadly, the cmd\git.exe entry point has been advertised as _the_ entry point for third-party applications, for a long time. So I cannot simply remove it.
On the other hand, it _is_ possible to use that entry point from cmd.exe even with MinGit, you just lose most of the interactive bells and whistles. In other words, I expect users who try to use MinGit other than in intended scenarios (i.e. as backend for some application requiring Git functionality) to know pretty well what they're doing, as they tread their own path (pun intended).
I think your credential manager cant locate the config file, because the folder-structure for MinGit is different as the folder-structure of the "usual" git.
The folder structure should be identical to same version of an installed Git for Windows. The only difference is that upgrades to the GCM have no way to find the instance of Mingit that you're interested in. You'll need to make sure to either manually place the version of the GCM you want into the 'mingw64/libexec/git-core/' folder OR use the 'git-credential-manager.exe' from the released zip archive and git-credential-manager install --path "path_to_mingit".
thank you for your helpfulness
our reason to take the portable "MinGit" was that we wanted to set up a correct configured "Git.zip" to rollout to the users in our company.
I recently found out, it would be also possible with our rollout-software, to install the real git and change the config files afterwards, so we will most likely take that way ^^ Lets hope that more common way will cause less problems
our reason to take the portable "MinGit" was that we wanted to set up a correct configured "Git.zip" to rollout to the users in our company.
Sounds like you really wanted PortableGit to begin with. Installed Git is usually a better experience for end-users as the installer correctly sets the %PATH% variable and other such niceties.
"useHttpPath = true" works fine now :+1:
Thank you for your help ^^