GitHub credential conflicts conflict with wincred credential helper

Question

I should be able to execute Git commands in two contexts:

• Inside Git (and the GitHub user interface for Windows)
• Double-clicking the batch files in Windows Explorer (I created a series of batch files that simplify the use of Git for non-technical contributors).

Everything works fine, except for push / pull operations where there is a credential issue. With the default installation of GitHub, which uses helper = !github –credentials in etc/.gitconfig , remote operating systems work fine for context 1, but not for context 2 (each time it requests credentials). If I add helper = wincred to user/.gitconfig , then context 1 works fine and context 2 works fine, although it complains first:

 github --credentials get: github: command not found github --credentials store: github: command not found 

(I assume that he complains because he is trying to use the GitHub helper, but cannot in context 2), but then proceeds to execute push:

 Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (5/5), 467 bytes | 0 bytes/s, done. Total 5 (delta 1), reused 0 (delta 0) ... 

I could live with a complaint, but the problem is that whenever GitHub for Windows starts, it removes helper = wincred from user/.gitconfig .

The question is: can I either

• Get context 1 for using wincred helper
• get a github assistant to work in context 2
• prevent GitHub for Windows from removing wincred (although this behavior is probably correct since I don't think you should have two credential assistants)
• install another credential assistant that will work in both contexts

Answer 1

I had a similar issue and contacted GitHub support and got this answer:

What you do is the configuration sanitizer that GitHub for Windows starts at startup. We have seen significant problems in the past with other Git clients adding invalid / bad configuration values ​​to this file and giving users a bad experience - so we had to take steps to mitigate these problems.

This is a failure, and you can work around this by running the following command:

git config --global ghfw.disableverification true

This fixed my problem.