Un equipo de ingeniería decidió probar Jujutsu (jj), un sistema de control de versiones compatible con Git que elimina el área de staging y facilita la reescritura del historial, con el objetivo de sustituir Git en su flujo diario. La iniciativa se topó con un obstáculo técnico concreto vinculado a los proyectos Gradle: el script gradlew.bat debe estar en formato CRLF para ejecutarse de forma fiable en Windows, una regla que los equipos aplican mediante .gitattributes (.bat text eol=crlf). Git aplica esa regla por archivo; jj, en cambio, no lee .gitattributes y solo permite configurar la conversión de finales de línea de forma global (working-copy.eol-conversion), equiparable al core.autocrlf de Git. En un repositorio colocalizado, Git almacena gradlew.bat como LF y lo entrega como CRLF, pero jj detecta el CRLF del disco y registra un cambio fantasma persistente contra el blob LF de Git. El problema está documentado en el issue jj-vcs/jj#53, donde otro usuario llegó a reportar cambios fantasma a escala de seis cifras. La solución propuesta por el autor de jj (un workspace no colocalizado) no resuelve el caso, porque jj materializa el archivo como LF y un gradlew.bat LF no funciona en Windows. Forzar CRLF global con working-copy.eol-conversion=input-output reescribe todos los archivos de texto. La salida funcional pasa por confirmar gradlew.bat con CRLF directamente y tratarlo como no normalizado (.bat -text), renunciando a la autocorrección que ofrecía eol=crlf. El equipo asume el coste y descarta jj hasta que llegue soporte real para eol por archivo, vía gix-filter u otro mecanismo. Mientras tanto, cubre la necesidad de múltiples directorios de trabajo con git worktree, que comparte el object store y evita clonados adicionales.
Noticias agregadas con IA