git mv y solo cambia el caso del directorio

7 minutos de lectura

git mv y solo cambia el caso del directorio
oschrenk

Si bien encontré una pregunta similar, no encontré una respuesta a mi problema

Cuando trato de cambiar el nombre del directorio de FOO a foo a través de git mv FOO foo yo obtengo

fatal: renaming 'FOO' failed: Invalid argument

está bien. así que lo intento git mv FOO foo2 && git mv foo2 foo

Pero cuando intento comprometerme a través de git commit . yo obtengo

# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# foo
nothing added to commit but untracked files present (use "git add" to track)

Cuando agrego el directorio a través de git add foo nada cambia y git commit . me vuelve a dar el mismo mensaje.

¿Qué estoy haciendo mal? Pensé que estaba usando un sistema que distingue entre mayúsculas y minúsculas (OSX), ¿por qué no puedo simplemente cambiar el nombre del directorio?

  • El sistema de archivos de OS X no distingue entre mayúsculas y minúsculas.

    – mipadi

    10 de junio de 2010 a las 4:47

  • @mipadi Puede operar en modo de distinción entre mayúsculas y minúsculas, pero generalmente está desactivado de forma predeterminada.

    – GordonM

    15 de junio de 2012 a las 12:07

  • Esta pregunta y sus respuestas también son útiles en Windows. Considere desetiquetar “osx”

    – Barett

    21/01/2015 a las 21:50


  • Ver stackoverflow.com/a/24979063/6309: desde git 2.0.1, un simple git mv obras.

    – VoC

    27 de marzo de 2015 a las 6:45

  • En windows puedes usar el regular git mv foo Foo si usa un shell cygwin.

    – Andrés Scott

    24 de junio de 2017 a las 9:51


git mv y solo cambia el caso del directorio
adam dimitruk

Estás en un entorno que no distingue entre mayúsculas y minúsculas. Además, agregar sin el -A no se ocupará del lado de extracción del mv como Git lo entiende. ¡Advertencia! ¡Asegúrese de que no haya otros cambios o archivos sin seguimiento cuando haga esto o se comprometerán como parte de este cambio! git stash -u primero haz esto y luego git stash pop después. Continuación: para evitar esto, haga lo siguiente:

mv foo foo2
git add -A
git commit -m "renaming"
mv foo2 FOO
git add -A
git commit --amend -m "renamed foo to FOO"

Esa es la forma extendida de cambiar el directorio de trabajo, confirmar y luego colapsar las 2 confirmaciones. Simplemente puede mover el archivo en el índice, pero para alguien que es nuevo en git, puede que no sea lo suficientemente explícito en cuanto a lo que está sucediendo. La versión más corta es

git mv foo foo2
git mv foo2 FOO
git commit -m "changed case of dir"

Como se sugiere en uno de los comentarios, también puede hacer una reorganización interactiva (git rebase -i HEAD~5 si el caso incorrecto se introdujo hace 5 confirmaciones) para arreglar el caso allí y que el caso incorrecto no aparezca en ninguna parte del historial. Debe tener cuidado si hace esto, ya que los hashes de confirmación a partir de ese momento serán diferentes y otros tendrán que reorganizar o volver a fusionar su trabajo con el pasado reciente de la rama.

Esto está relacionado con la corrección del nombre de un archivo: ¿Git no distingue entre mayúsculas y minúsculas?

  • Gracias. Esto me estaba volviendo loco. No conocía la opción -A o –amend.

    – oschrenk

    10 de junio de 2010 a las 5:18


  • Tenga cuidado con la -A, ya que agregará recursivamente todo el contenido en su directorio actual, incluido el material no rastreado. Podría ser mejor simplemente git add foo2.

    – rico.e

    22 de diciembre de 2012 a las 4:00

  • Eso es correcto. Sin embargo, deberá organizar tanto la eliminación de foo2 como la adición de FOO por separado. -A se ocupa de los dos. Viceversa para el primer paso. Añadiré la advertencia. ¡Gracias!

    – Adam Dimitruk

    23/12/2012 a las 20:00

  • También puedes limpiar tu historial con un rebase interactivo git rebase -i HEAD~2. Nota: Para simplificar esto, configure el mensaje final en su primera confirmación y corrija la segunda.

    – Alex B.

    21 de agosto de 2013 a las 12:47


  • Tuve éxito con git mv foo foo2; git mv foo2 FOO; git cometer

    – Chris

    2 de julio de 2015 a las 19:04


Quiere configurar la opción core.ignorecase a falso, lo que hará que Git preste atención al caso en los sistemas de archivos que no lo admiten de forma nativa. Para habilitar en su repositorio:

$ git config core.ignorecase false

Luego puede cambiar el nombre del archivo con git mv y funcionará como se esperaba.

  • Creo que esto puede tener efectos indeseables en otros lugares. Los sistemas que no distinguen entre mayúsculas y minúsculas deberían permitir que Git piense que es el mismo directorio.

    – Adam Dimitruk

    10 de junio de 2010 a las 5:00

  • Agregué la opción a mi configuración global pero no ayudó

    – oschrenk

    10 de junio de 2010 a las 5:20

  • Veo un comportamiento extraño al usar esto con OSX. hmm I modified a file that doesn't exist .. mmm error: The following untracked working tree files would be overwritten by checkout: pero… esos archivos no existen.

    – Skylar Salvatierra

    26 de agosto de 2011 a las 15:04

  • Esto era exactamente lo que estaba buscando. Estoy ejecutando CentOS 5.6 y no detectó el cambio de caso.

    – crmpicco

    10 de abril de 2014 a las 8:31

  • ¡Esto no funciona! En Git 1.8.3, Git tratará el archivo renombrado como un archivo nuevo, en lugar de eliminarlo + agregarlo. Si lo confirma, dejará el repositorio con dos archivos iguales, por ejemplo, ¡foo y FOO existen! Pero cuando se paga solo aparece un archivo (pero un caso puede dominar sobre el otro caso)

    – Johnny Wong

    21 de abril de 2015 a las 3:44

1646753897 416 git mv y solo cambia el caso del directorio
mgadda

Pude resolver esto usando git 1.7.7 usando un nombre de archivo temporal:

$ git mv improper_Case improve_case2
$ git mv improve_case2 improve_case
$ git commit -m "<your message>"

  • Interesante. Quizás GIT mejoró algo desde entonces. Cuando vuelva a encontrarme con este problema, lo intentaré de nuevo.

    – oschrenk

    29 de mayo de 2012 a las 12:04

  • mucho más fácil hacerlo de esta manera

    – olor

    17 de julio de 2012 a las 22:04

  • Trabajó para mí en macOS.

    – Mr_Pouet

    5 de abril de 2017 a las 18:56

(git mv-variante libre.)

Me encontré con este problema en Git en Mac OS X 10.9. Lo resolví de la siguiente manera:

git rm -r --cached /path/to/directory

Eso organiza el directorio para su eliminación en Git pero en realidad no elimina ningún archivo físico (--cached). Esto también hace que el directorio, ahora con las mayúsculas y minúsculas adecuadas, aparezca en archivos sin seguimiento.

Así que puedes hacer esto:

mv /path/to/directory /path/to/DIRECTORY
git add -A /path/to/DIRECTORY

Git reconocerá que ha cambiado el nombre de los archivos y, cuando lo haga, git status deberías ver un número de renamed: líneas. Revíselos y asegúrese de que se vean correctos, y si es así, puede confirmar los cambios normalmente.

1646753898 692 git mv y solo cambia el caso del directorio
Nick Volynkin

Esta es una solución rápida y a prueba de errores:

git mv -f path/to/foo/* path/to/FOO/

¡Advertencia! Cambie siempre el nombre de todos los archivos en la carpeta renombrada (utilice /*).

No cambie el nombre de los archivos individuales. Esto conduce a un error, descrito en esta respuesta.

Si primero quiere ver el resultado primero, use -n:

git mv -f -n path/to/foo/* path/to/FOO/

Después de haber hecho un mv:

  1. Cometer cambios
  2. Checkout a cualquier otra revisión
  3. Pagar atrás.

Ahora Git debería haber cambiado el nombre de la carpeta AMBOS en sus archivos internos y en el sistema de archivos.

  • ¿Esto es solo para Git 2.0.1 como mencioné en los comentarios de preguntas anteriores? (en referencia a stackoverflow.com/a/24979063/6309)

    – VoC

    11 de junio de 2015 a las 19:29

1646753898 239 git mv y solo cambia el caso del directorio
konyak

Forzarlo con la opción -f:

git mv -f FOO foo

  • ¿Esto es solo para Git 2.0.1 como mencioné en los comentarios de preguntas anteriores? (en referencia a stackoverflow.com/a/24979063/6309)

    – VoC

    11 de junio de 2015 a las 19:29

Tuve un problema relacionado.

Una carpeta llamada ‘Pro’ (creada primero) y otra ‘pro’ (creada por error). En Mac es lo mismo, pero diferente según git.

$ git config core.ignorecase false

la configuración de git cambió el nombre de los archivos a la carpeta correcta (gracias) y también creó archivos fantasma en ‘pro’ (¡No!). No pude agregar cambios de archivos fantasma a la pista y no pude verificar otras ramas a menos que lleve esos archivos conmigo, y tampoco pude restablecerlo de alguna manera.

En lugar de eso, hice

$ git rm -r --cached pro
$ git status // => pro files removed, new Pro files untracked
$ git add Pro

Para hacerlo más seguro, lo hice en una rama de reparación separada y luego me fusioné de nuevo con la rama principal.

Para el problema del archivo fantasma creado por , ¿algún gurú puede explicar cómo y por qué? Gracias por adelantado.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad