Set credential.helper=manager in archives release

[fcollonval]

• [ x ] I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.19.0.windows.1
cpu: x86_64
built from commit: d96bb8bc6c636a8869140e860e72e7bdf64bd790
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Windows 7 64bits

$ cmd.exe /c ver

Microsoft Windows [version 6.1.7601] 

• What options did you set as part of the installation? Or did you choose the
  defaults?

Test on

• MinGit-2.19.0-busybox-64-bit.zip
• Git-2.19.0-64-bit.tar.bz2

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

• Feature request

Scenario: to include git in (Python) conda environment, a package is built from MinGit with busybox. It took me some times to figure out that Git-Credential-Manager-for-Windows was present but not set by default. And therefore why git calls in subprocess were failing (although credentials were already registered within Windows Identification Safe).

Test:
I tested archives release for 2.19 (full Git and MinGit with busybox). They both don't set the Git-Credential-Manager-for-Windows by default.

Idea:
Setting Git-Credential-Manager-for-Windows as credential.helper in system config file for the archives release.

[dscho]

The purpose of MinGit is to serve as "Git for Applications". As such, it purposefully cuts out all interactive commands. Git Credential Manager is interactive. I am not sure how much we would break by setting credential.helper = manager by default. I'd rather not find out.

[fcollonval]

Thanks for the answer. I'll keep setting it in my installation script then.