El clon de Git falla con "fatal: múltiples actualizaciones para ref 'refs/tags/v1.0.0' no permitidas" en MacOS Mojave

Hice muchas operaciones en mi computadora anoche, básicamente actualizando/mejorando (?) brew, que instaló una nueva versión de git, python actualizado, muchas cosas y hoy pensé que ya no podía clonar un repositorio.

git clone git@github.com:UnlyEd/serverless-plugin-dynamodb-backups.git
Cloning into 'serverless-plugin-dynamodb-backups'...
remote: Enumerating objects: 589, done.
remote: Total 589 (delta 0), reused 0 (delta 0), pack-reused 589
Receiving objects: 100% (589/589), 304.18 KiB | 862.00 KiB/s, done.
Resolving deltas: 100% (333/333), done.
fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

Intenté diferentes repositorios, obtengo el mismo error cada vez, por lo que es mi instalación la que está rota de alguna manera.

Intenté desinstalar/reinstalar git (con brew) pero no cambió nada.

Revisé otros comandos de git y todavía puedo extraer/confirmar

estoy usando git 2.21.0

Realmente no sé qué hacer para solucionarlo y no sé qué causó esto. Además, no uso el comando git clone a diario, por lo que podría haberse roto antes, pero siento que está relacionado con la actualización de homebrew.


Adición de más detalles basados ​​en comentarios/preguntas:

type git
git is an alias for LANG=en_GB git

mkdir ~/gitclone && cd ~/gitclone && git clone git@github.com:UnlyEd/serverless-plugin-dynamodb-backups.git
Cloning into 'serverless-plugin-dynamodb-backups'...
remote: Enumerating objects: 589, done.
remote: Total 589 (delta 0), reused 0 (delta 0), pack-reused 589
Receiving objects: 100% (589/589), 304.18 KiB | 828.00 KiB/s, done.
Resolving deltas: 100% (333/333), done.
fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed
¿Qué devuelve ˋtype gitˋ? ¿Qué sucede si ejecuta ˋmkdir ~/gitclone && cd ~/gitclone && git clone NAMEOFREMOTEREPˋ?
@nohillside Agregué la salida que pediste. Nada fuera de lo común, diría yo para gitel mando. Parece que el problema tampoco está relacionado con una carpeta en particular, es de todo el sistema.

Respuestas (2)

¿Tienes un .gitconfig personalizado? Tuve que eliminar el siguiente parámetro del mío para que la clonación volviera a funcionar:

[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*

git v2.21.0fue lanzado hace unos días, por lo que tal vez algo cambió bajo el capó. Necesito ir a ver las notas de la versión.

De todos modos, ¡espero que esto ayude!


Al agregar un poco más de contexto de fondo, esta línea era muy común para obtener las etiquetas de forma predeterminada. Permitió hacer git fetchlo que también haría un git fetch --tagsequivalente debajo del capó.

Básicamente, si desea obtener etiquetas cuando hace una git fetchcon esta versión git v2.21, puede crear un alias en su .gitconfigde la siguiente manera:

[alias]
    fetch = git fetch --tags

Hacer esto y eliminar dará fetch = +refs/heads/*:refs/remotes/origin/*como resultado el mismo comportamiento, pero compatible con git v2.21

Consulte https://stackoverflow.com/questions/1204190/does-git-fetch-tags-include-git-fetch/20608181#20608181 para obtener una explicación detallada y cambios en el historial.

¡En efecto! Esa fue la razón :) ¡Gracias! Todavía no puedo otorgar la recompensa debido a la política SO, pero lo tienes Jon, está funcionando de nuevo
Y ni siquiera sé qué remote "origin"se suponía que debía hacer esta configuración, la tenía porque un compañero de trabajo la estaba usando, hace años y la conservé porque por qué no. Tal vez sea una buena práctica con el antiguo binario git, me encantaría saber para qué sirve y si debería reemplazarlo por algo más;)
Yo tampoco estoy muy seguro. Aquí hay algo de documentación sobre refspec . Quizás alguien más inteligente que nosotros pueda proporcionar más información :)
Parece que estaba destinado a buscar las etiquetas de forma predeterminada cuando se ejecuta git fetchsin tener que hacerlo manualmente git fetch --tags, consulte stackoverflow.com/questions/16678072/…
Otro enlace más detallado, muy explicativo: stackoverflow.com/questions/1204190/…
¡Actualicé su respuesta para agregar más antecedentes y explicar la configuración necesaria con v2.21 que resultó en el comportamiento anterior! :) (recibí ayuda de amigos para resolverlo :D)
Estoy confundido, ¿entonces Git permite anular los comandos integrados ahora? Anteriormente, los alias no estaban permitidos explícitamente para los comandos integrados (como fetch).
tenga en cuenta que, a diferencia de refspec, git fetch --tagsno obtendrá etiquetas actualizadas; No conozco una buena manera de no obtener este error en el clon y obtener etiquetas actualizadas.

No estoy seguro de si este es el problema aquí, pero ¿ha verificado si la carpeta en la que está tratando de clonar está vacía? También verifique si la carpeta en la que está tratando de clonar ya está administrada por otro repositorio de git.

Puede verificar si es un repositorio de git haciendo git statusy ver si debería ser fatal: not a git repository (or any of the parent directories): .git.

Hum, no creo que esté relacionado con el problema en absoluto. El comando git clone git@github.com:UnlyEd/serverless-plugin-dynamodb-backups.gitque no especifica un directorio creará uno por defecto. Y es totalmente posible clonar un repositorio de git desde dentro de otro repositorio de git :)
Tienes razón en ambos. Mi duda es que un repositorio de git principal tenga algún error que esté causando este problema. De todos modos, estos no son el problema que está teniendo.