My original answer turned out to not be very useful even for myself, so I looked a bit more into it, and I found a hack (albeit somewhat complicated).
So, I use git under MSYS2, and I would like to use credential-cache, to just remember my password temporarily (and I haven't seen such a use case with wincred or other Windows-applicable approaches).
Basically, this requires a hack in https://github.com/git/git/blob/55144cc/builtin/credential-cache--daemon.c#L239 - instead of die-ing in that line, we'd like to proceed.
So, first of all, we want to build git under MSYS2.
- Problem 1: You cannot just build the proper https://github.com/git/git under MSYS2, linking stage will fail with "src/git/cache.h:1262: undefined reference to `win32_has_dos_drive_prefix'" and similar messages
So, we need to build the actual git as used in MSYS2. First, check versions:
$ git --version
git version 2.33.0
$ pacman -Ss git | grep installed # msys/git 2.33.0-1 (VCS) [installed]
Then, as per https://www.msys2.org/wiki/Creating-Packages/, we can do this:
$ git clone "https://github.com/msys2/MSYS2-packages"
$ cd MSYS2-packages/
$ cd git
$ makepkg -sCLf
==> Making package: git 2.33.0-1 (Thu, Sep 23, 2021 12:47:33 PM)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
...
make[1]: Entering directory '/c/src/MSYS2-packages/git/src/git-2.33.0'
make[1]: 'GIT-VERSION-FILE' is up to date.
make[1]: Leaving directory '/c/src/MSYS2-packages/git/src/git-2.33.0'
sed -e '1s|#!.*/sh|#!/bin/sh|' git-subtree.sh >git-subtree
chmod +x git-subtree
make: Leaving directory '/c/src/MSYS2-packages/git/src/git-2.33.0/contrib/subtree'
==> Starting check()...
Note here:
- This build process first ends up in a ASCIIDOC/XMLTO part, which like takes half an hour on my machine
- Then it ends up in a
*** prove *** part which takes even longer, but can be interrupted with Ctrl-C, and the built executables will not be erased.
So, now we want to do a hack in the source; note:
- If we do a hack in the source, we do NOT want to use
makepkg -sCLf, because that will erase the source directory (along with all the built .exe artefacts), and then reconstruct it before build
So, we make our hack with sed, and then build:
$ sed -i 's/die(_(permissions_advice), dir);/fprintf(stderr, "Permissions on cached credentials socket directory %s are too loose, but HACK: going on\\n", dir);/' ./src/git-2.33.0/builtin/credential-cache--daemon.c
$ (cd src/git-2.33.0/; make)
CC builtin/credential-cache--daemon.o
LINK git.exe
...
SUBDIR templates
At this point, note that the hack ends up in at least three executables, which can be confirmed with:
$ grep -ao ....HACK........ ./src/git-2.33.0/git-credential-cache--daemon.exe
$ grep -ao ....HACK........ ./src/git-2.33.0/git-credential-cache.exe
$ grep -ao ....HACK........ ./src/git-2.33.0/git.exe
... and I could only get this to work, after replacing all three:
# backup the original files:
$ mv /usr/lib/git-core/git-credential-cache--daemon.exe /usr/lib/git-core/__git-credential-cache--daemon_orig.exe
$ mv -v /usr/lib/git-core/git-credential-cache.exe /usr/lib/git-core/__git-credential-cache__orig.exe
$ mv -v /usr/bin/git.exe /usr/bin/__git_orig.exe
$ mv -v /usr/lib/git-core/git.exe /usr/lib/git-core/__git_orig.exe
# copy over the hacked files:
cp -v ./src/git-2.33.0/git-credential-cache--daemon.exe /usr/lib/git-core/
cp -v ./src/git-2.33.0/git-credential-cache.exe /usr/lib/git-core/
cp -v ./src/git-2.33.0/git.exe /usr/bin/
cp -v ./src/git-2.33.0/git.exe /usr/lib/git-core/
And at this point, credential-cache started working also for me on MSYS2 (caching passwords for a limited amount of time); it's just that it dumps the hacked line when starting up:
$ git pull
Password for 'https://[email protected]':
Permissions on cached credentials socket directory /home/user/.cache/git/credential are too loose, but HACK: going on
Already up to date.
# second pull, password is cached
$ git pull
Already up to date.
A bit tricky, but seems to work.
PS: A tricky thing was, that I originally replaced die with just a printf to stdout, but that kept on failing; it turns out, stdout is used for interprocess communication, and for this to succeed, something apparently answers ok\0 on stdout which is three bytes; so the solution was to print the notice to stderr instead.
(original answer):
While not responsive to the question exactly as asked, this was the most appropriate question I could find, to document this as an answer:
I use git under MSYS2 in Windows 10, which currently has the version:
$ git --version
git version 2.32.0
I typically just want git to cache my password for a limited time (maybe 10 minutes or so) and then forget about it; and I haven't yet seen uses of wincred or other Windows-specific credential manager with that use case.
That being said, turns out for me there is an "easy fix" - basically, the first time credential manager runs, it is fine; it is only upon subsequent uses that I get:
$ git push
Password for 'http://[email protected]':
fatal: The permissions on your socket directory are too loose; other
users may be able to read your cached credentials. Consider running:
chmod 0700 /home/user/.cache/git/credential
fatal: cache daemon did not start:
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
...
So, basically, the fix is to delete the credential directory - thereafter, the credential cache manager runs as if for the first time, and caches the passwords for a limited time - just as I want it:
$ rm -rf ~/.cache/git/credential
# note below, the very first pull still asks for a password:
$ git pull
Password for 'http://[email protected]':
Already up to date.
# ... but the second pull does not, it uses credentials cache
$ git pull
Already up to date.
Good enough for me, I guess :)
EDIT: not really, I've experienced that immediately after this, if you try a pull in another tab, the error returns.
--global. – Robgit config credential.helper cachedid work for me with Cygwin git version 2.13.2. – Unsexgit config --global -eandgit config --local -eIn trying to reset my credentials in Windows, I accidently added a line to the local file causing the error. To remove the credentials I followed stackoverflow.com/questions/15381198/… which worked. – Georgia