¿Por qué Git bloquea el cambio de versión en ComfyUI y cómo solucionarlo

Estaba intentando actualizar mi entorno de ComfyUI a la versión nightly usando el ComfyUI Manager 4.2.2, pero me encontré con un bloqueo inesperado. Al ejecutar el cambio de versión desde la interfaz, el sistema arrojó una alerta y dejó caer un traceback en los logs que parecía indicar un fallo grave.

Terminal mostrando un traceback de errores de Git y Python relacionados con el cambio de versiones.
Captura de pantalla del error de Git al intentar cambiar la versión de ComfyUI y los conflictos en requirements.txt.

Analizando el error al principio, la raíz del problema estaba bastante clara. El Manager intentaba ejecutar una orden de git checkout master, pero Git se negó a proceder porque detectó cambios locales en mi carpeta de trabajo.

El conflicto con requirements.txt

La clave estaba en el archivo requirements.txt. El error original indicaba que los cambios locales en este archivo serían sobrescritos por el cambio de rama. Esto significa que alguien —o algo del entorno— había modificado las dependencias antes de intentar el upgrade.

Además, hubo un segundo error extraño en los logs: TypeError: Logger._log() got an unexpected keyword argument 'file'. Tras investigar, es claro que este no era la causa principal. Era simplemente un bug del ComfyUI Manager 4.2.2 al intentar reportar el fallo inicial.

¿Qué hice con Kornia?

Aquí llegó una decisión importante. Al ver que el archivo estaba modificado, decidí editar la línea de Kornia directamente en el requirements.txt, cambiando kornia>=0.7.1 a kornia==0.7.1. Pensé que esto me ahorraría pasos si necesitaba instalar LTXVideo después.

Sin embargo, esa edición fue exactamente lo que hizo que Git se pusiera quisquilloso. El sistema consideró mi cambio como algo valioso que debía proteger antes de sobrescribirlo durante el switch de versión.

Cómo solucionarlo

Para destrabar esta situación, hay varias estrategias efectivas:

  • Opción A (Restaurar): Usando git checkout -- requirements.txt, puedes devolver el archivo a su estado original upstream y proceder con el cambio de rama.
  • Opción B (Stash): Si quieres conservar tus cambios, usa git stash, cambia de versión primero, y luego reaplica tu parche con git stash pop.
  • Estrategia a largo plazo: Para evitar este tipo de conflictos en el futuro, es recomendable mantener repositorios separados para entornos stable y nightly, evitando así mezclar dependencias que podrían romperse.

Volviendo al archivo original, congelar la versión a kornia==0.7.1 también tiene sus riesgos, ya que podrías perder acceso a fixes futuros necesarios para ciertas librerías de video.