Git: remoto: fatal: archivo de índice corrupto, “el índice usa la extensión yz”?

Acabo de encontrar un problema que nunca había visto antes y no puedo encontrar ninguna ayuda.

Ejecuto un repositorio de git master en el sitio web en vivo en nuestro entorno de alojamiento y un repositorio de origen simple en el mismo servidor. Todas las confirmaciones de nuestro desarrollador van al maestro de origen simple, que tiene un enlace posterior a la recepción para enviar cada confirmación al repositorio maestro para que el envío se refleje en los archivos del sitio en vivo. La única molestia es que cada vez que recibimos actualizaciones de WordPress, tenemos que comprometernos con el repositorio principal y luego enviarlo de vuelta al repositorio de origen para que nuestros desarrolladores puedan descargar esos archivos actualizados.

Problema: Hoy, fui a confirmar una actualización del complemento de WordPress, y la confirmación funcionó bien, pero el impulso dio el siguiente error críptico en el que no puedo encontrar ninguna ayuda:

git push origin master

Counting objects: 344, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (323/323), done.
Writing objects: 100% (344/344), 1.76 MiB | 5.61 MiB/s, done.
Total 344 (delta 237), reused 14 (delta 1)
remote: Resolving deltas: 100% (237/237), completed with 226 local objects.
remote: Running post-receive (git pull origin master):
remote: error: index uses ▒yz▒ extension, which we do not understand
remote: fatal: index file corrupt

(Los símbolos extraños alrededor de las letras “yz” dicen “<B3>yz<AC>” cuando ejecuto git diff)

si corro git status en el maestro (no se puede ejecutar en el origen ya que es un repositorio simple), repite las dos últimas líneas de salida. si corro git log en ambos repositorios, se ven normales, pero el origen es, por supuesto, un compromiso detrás del maestro, porque el compromiso con el maestro funcionó, pero el envío al origen falló.

Nunca antes había oído hablar de esta extensión “yz” y, por lo que sé, nadie más lo ha hecho. Todo lo que hice fue un compromiso y un empujón y el empujón falló. No usamos ninguna extensión “yz”, usamos Vanilla Git, hacemos push y pulls muy básicos, nuestro enlace posterior a la recepción es sobre un script de 5 líneas que simplemente empuja automáticamente cada confirmación desde el origen hasta el maestro y restablece los permisos de archivo a asegúrese de que sean legibles por el servidor web. Lo único extraño que estamos haciendo es usar Git para administrar un sitio de WordPress para el control de versiones. Todos los desarrolladores usan TortoiseGit en Windows sin configuraciones especiales ni complementos.

He visto muchas preguntas y respuestas sobre índices corruptos, pero nada como esto.

Todavía no he probado nada porque no estoy seguro de qué hacer, no entiendo el funcionamiento interno de Git y no quiero romper nada, pero necesitamos poder tirar y empujar y no podemos hasta que los repositorios estén sincronizado de nuevo.

Muy bien, esto es lo que hice:

Debido a que no quería perder ningún cambio en el repositorio principal (índice corrupto), ya que los cambios debían mantenerse y también enviarse al origen (índice de trabajo), ejecuté lo siguiente:

rm .git/index
git reset --mixed

(mixto es la opción predeterminada)

Según la documentación:

--mixed
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

Gracias a torek y bk2204 por su ayuda para comprender la situación y un poco de búsqueda en Google para descubrir el proceso más seguro para restablecer un índice sin perder ningún archivo confirmado o en funcionamiento.

Todo lo precedido de remote: no vino de su Git pero de su Git: el Git que llamó su Git, en la URL que usó cuando ejecutó git push.

Es su Git que se está quejando su índice de Git. Este es probablemente un problema de corrupción de archivos en su máquina. Necesita que ellos, quienesquiera que sean “ellos”, revisen su sistema. Si todo se ve bien, probablemente deberían eliminar y reconstruir sus archivos de índice.

(Si “ellos” https://stackoverflow.com/”ellos” es realmente usted, diríjase a la(s) máquina(s) involucrada(s), inspeccione cuidadosamente en busca de daños o discos que estén en llamas o lo que sea, y si todo se ve bien , elimine y reconstruya los archivos de índice).