Eliminar una línea vacía de ~/.git-credentials resolvió el problema por mí.

Tuve el mismo problema al usar git en ubuntu y una "tienda" auxiliar de credenciales de git. La actualización a git 1:2.17.1-1ubuntu0.7 (ver aquí ) trajo el problema. Esta actualización de seguridad agrega comprobaciones más estrictas de las direcciones URL de las credenciales. Parece que la línea vacía se malinterpreta como una URL incorrecta.

Esto debería resolverse con With Git 2.27 (Q2 2020).

Las actualizaciones recientes interrumpieron el análisis de " credential.<url>.<key> " donde <url> no es una URL completa (por ejemplo [credential "https://"] helper = ... ) dejó de funcionar: eso se solucionó.

Consulte la confirmación 9a121b0 , la confirmación 6828e59 , la confirmación 21920cb (24 de abril de 2020) de Johannes Schindelin ( dscho ) .
^{(Fusionado por Junio C Hamano -- gitster -- en commit da05cac , 5 de mayo de 2020)}

credential : manejar credential.<partial-URL>.<key> nuevo

^{Firmado por: Johannes Schindelin
Revisado por: Carlo Marcelo Arenas Belón}

En los parches para CVE-2020-11008, se perdió la capacidad de especificar configuraciones de credenciales en la configuración para URL parciales. Por ejemplo, solía ser posible especificar un asistente de credenciales para un protocolo específico:

 [credential "https://"] helper = my-https-helper

Asimismo, solía ser posible configurar ajustes para un host específico, por ejemplo:

 [credential "dev.azure.com"] useHTTPPath = true

Vamos a restablecer este comportamiento.

Mientras lo hace, aumente la cobertura de la prueba para documentar y verificar el comportamiento con un par de otras categorías de URL parciales.

Y:

credential : opcionalmente, permite URL parciales en credential_from_url_gently()

^{Firmado por: Johannes Schindelin
Revisado por: Carlo Marcelo Arenas Belón}

Antes de las correcciones para CVE-2020-11008, éramos _very _ indulgentes con lo que requeríamos de una URL para analizarla en una struct credential . Eso condujo a serias vulnerabilidades.

Sin embargo, había un sitio de llamadas que realmente necesitaba esa indulgencia: al analizar los ajustes de configuración a la credential.dev.azure.com.useHTTPPath .
Es posible que se deseen configuraciones como esta cuando los usuarios desean usar, por ejemplo, un nombre de usuario dado en un host determinado, independientemente del protocolo que se use.

Finalmente:

Con el reciente endurecimiento del código que se usa para analizar varias partes de una URL para su uso en el subsistema de credenciales, un archivo de almacenamiento de credenciales editado a mano hace que el asistente de credenciales muera, lo que es demasiado duro para los usuarios.

Reduzca el comportamiento del error para simplemente ignorarlo y seguir usando líneas bien formadas.

Ver commit c03859a (02 de mayo de 2020) de Carlo Marcelo Arenas Belón ( carenas ) .
Consulte el compromiso 20b4964 (28 de abril de 2020) de Junio C Hamano ( gitster ) .
^{(Fusionado por Junio C Hamano -- gitster -- en commit 933fdf8 , 8 de mayo de 2020)}

credential-store : ignora las líneas falsas del archivo de la tienda

^{Reportado por: Dirk
Ayudado por: Eric Sunshine
Ayudado por: Junio C Hamano
Basado en el parche de: Jonathan Nieder
Firmado por: Carlo Marcelo Arenas Belón}

Con las comprobaciones añadidas de direcciones URL no válidas en las credenciales, se informó que los archivos almacenados modificados localmente que pudieran tener líneas vacías o incluso comentarios no se podían analizar como credenciales válidas.

(informado en esta misma página por el OP)

En lugar de hacer una verificación estricta de las credenciales, haga una suave y, por lo tanto, evite el error fatal informado.

Mientras tanto, agregue pruebas para todas las corrupciones conocidas que actualmente se ignoran para realizar un seguimiento de ellas y evitar el riesgo de regresiones.

Yo tuve el mismo problema. Lo que me ayudó fue lo siguiente:

Con

 git config -l

Descubrí que había un ajuste

 credential.[URL].username=[SOME-USERNAME]

Eliminé esto usando

 git config --unset credential.[URL].username

Entonces las cosas funcionaron de nuevo.