Manejo de nombres de archivos en git

Leí que al cambiar el nombre de los archivos en git , debe confirmar cualquier cambio, realizar su cambio de nombre y luego organizar su archivo renombrado. Git reconocerá el archivo por el contenido, en lugar de verlo como un nuevo archivo sin seguimiento, y mantendrá el historial de cambios.

Sin embargo, haciendo esto esta noche, terminé volviendo a hacerlo git mv.

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#

Cambiar el nombre de mi hoja de estilo en Finder de iphone.cssamobile.css

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    css/iphone.css
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   css/mobile.css

Entonces git ahora piensa que eliminé un archivo CSS y agregué uno nuevo. No es lo que quiero, deshaga el cambio de nombre y deje que git haga el trabajo.

> $ git reset HEAD .
Unstaged changes after reset:
M   css/iphone.css
M   index.html

De vuelta a donde empecé.

> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   index.html
#

Vamos a usar git mven su lugar.

> $ git mv css/iphone.css css/mobile.css
> $ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   renamed:    css/iphone.css -> css/mobile.css
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   index.html
#

Parece que estamos bien. Entonces, ¿por qué git no reconoció el cambio de nombre la primera vez cuando usé Finder?

Para git mvla página del manual dice

El índice se actualiza después de completar con éxito, […]

Entonces, al principio, debe actualizar el índice por su cuenta (mediante el uso git add mobile.css). Sin embargo
git status , aún mostrará dos archivos diferentes

$ git status
# On branch master
warning: LF will be replaced by CRLF in index.html
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   index.html
#       new file:   mobile.css
#
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    iphone.css
#

Puede obtener un resultado diferente ejecutando git commit --dry-run -a, lo que da como resultado lo que espera:

Tanascius@H181 /d/temp/blo (master)
$ git commit --dry-run -a
# On branch master
warning: LF will be replaced by CRLF in index.html
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   index.html
#       renamed:    iphone.css -> mobile.css
#

No puedo decirte exactamente por qué vemos estas diferencias entre git statusy
git commit --dry-run -a, pero aquí hay una pista de Linus :

git realmente ni siquiera se preocupa por toda la "detección de cambio de nombre" internamente, y cualquier confirmación que haya realizado con los cambios de nombre es totalmente independiente de la heurística que luego usamos para mostrar los cambios de nombre.

A dry-runutiliza los mecanismos de cambio de nombre reales, mientras que git statusprobablemente no.

Debe agregar los dos archivos modificados al índice antes de que git lo reconozca como un movimiento.

La única diferencia entre mv old newy git mv old newes que git mv también agrega los archivos al índice.

mv old newentonces git add -Ahabría funcionado también.

Tenga en cuenta que no puede usarlo simplemente git add .porque eso no agrega eliminaciones al índice.

Vea la diferencia entre "git add -A" y "git add".

Lo mejor es probarlo por ti mismo.

mkdir test
cd test
git init
touch aaa.txt
git add .
git commit -a -m "New file"
mv aaa.txt bbb.txt
git add .
git status
git commit --dry-run -a

Ahora git status y git commit --dry-run -a muestra dos resultados diferentes donde git status muestra bbb.txt cuando se elimina un nuevo archivo / aaa.txt, y los comandos --dry-run muestran el cambio de nombre real.

~/test$ git status

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   bbb.txt
#
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    aaa.txt
#


/test$ git commit --dry-run -a

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   renamed:    aaa.txt -> bbb.txt
#

Ahora ve y haz el check-in.

git commit -a -m "Rename"

Ahora puede ver que el archivo ha cambiado de nombre y que lo que se muestra en estado de git es incorrecto.

Moraleja de la historia: si no está seguro de si se cambió el nombre de su archivo, emita un "git commit --dry-run -a". Si muestra que el archivo se renombra, está listo para comenzar.

Para git 1.7.x, los siguientes comandos me funcionaron:

git mv css/iphone.css css/mobile.css
git commit -m 'Rename folder.' 

No había necesidad de git add, ya que el archivo original (es decir, css / mobile.css) ya estaba en los archivos confirmados anteriormente.

tienes que acceder al git add css/mobile.cssnuevo archivo y git rm css/iphone.css, por lo tanto, git lo sabe. entonces mostrará la misma salida engit status

puede verlo claramente en la salida de estado (el nuevo nombre del archivo):

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)

y (el antiguo nombre):

# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)

Creo que detrás de escena git mvno es más que un script de envoltura que hace exactamente eso: eliminar el archivo del índice y agregarlo con un nombre diferente

Pensemos en sus archivos desde la perspectiva de git.

Tenga en cuenta que git no rastrea ningún metadato sobre sus archivos

Tu repositorio tiene (entre otros)

$ cd repo
$ ls
...
iphone.css
...

y está bajo control de git:

$ git ls-files --error-unmatch iphone.css &>/dev/null && echo file is tracked
file is tracked

Prueba esto con:

$ touch newfile
$ git ls-files --error-unmatch newfile &>/dev/null && echo file is tracked
(no output, it is not tracked)
$ rm newfile

Cuando tu lo hagas

$ mv iphone.css mobile.css

Desde la perspectiva de git,

• no hay iphone.css (se elimina -git advierte sobre eso-).
• hay un nuevo archivo mobile.css .
• Esos archivos no tienen ninguna relación.

Entonces, git aconseja sobre los archivos que ya conoce ( iphone.css ) y los nuevos archivos que detecta ( mobile.css ), pero solo cuando los archivos están en el índice o HEAD git comienza a verificar su contenido.

En este momento, ni "iphone.css deletion" ni mobile.css están en el índice.

Agregue la eliminación de iphone.css al índice

$ git rm iphone.css

git te dice exactamente lo que sucedió: ( iphone.css se elimina. No pasó nada más)

luego agregue un nuevo archivo mobile.css

$ git add mobile.css

Esta vez, tanto la eliminación como el nuevo archivo están en el índice. Ahora git detecta que el contexto es el mismo y lo expone como un cambio de nombre. De hecho, si los archivos son 50% similares, lo detectará como un cambio de nombre, lo que le permite cambiar un poco mobile.css mientras mantiene la operación como un cambio de nombre.

Ver esto es reproducible en git diff. Ahora que sus archivos están en el índice, debe usarlos --cached. Edite mobile.css un poco, agréguelo al índice y vea la diferencia entre:

$ git diff --cached 

y

$ git diff --cached -M

-Mes la opción "detectar cambios de nombre" para git diff. -Msignifica -M50%(50% o más de similitud hará que git lo exprese como un cambio de nombre) pero puede reducir esto a -M20%(20%) si edita mucho mobile.css.

Paso 1: cambie el nombre del archivo de oldfile a newfile

git mv #oldfile #newfile

Paso 2: git commit y agrega comentarios

git commit -m "rename oldfile to newfile"

Paso 3: empuje este cambio a servidor remoto

git push origin #localbranch:#remotebranch

Git reconocerá el archivo por el contenido, en lugar de verlo como un nuevo archivo sin seguimiento

Ahí es donde te equivocaste.

Solo después de agregar el archivo, git lo reconocerá por el contenido.

No diste los resultados de tu movimiento de búsqueda. Creo que si hiciste el movimiento a través del Finder y luego lo hiciste git add css/mobile.css ; git rm css/iphone.css, git calcularía el hash del nuevo archivo y solo entonces te darías cuenta de que los hash de los archivos coinciden (y, por lo tanto, es un cambio de nombre).

En casos en los que realmente tiene que cambiar el nombre de los archivos manualmente, por ejemplo. usando una secuencia de comandos para cambiar el nombre de un lote de archivos por lotes, luego usando git add -A .funcionó para mí.

Para usuarios de Xcode: si cambia el nombre de su archivo en Xcode, verá que el icono de la insignia cambia para agregarse. Si realiza una confirmación utilizando XCode, en realidad creará un nuevo archivo y perderá el historial.

Una solución alternativa es fácil, pero debe hacerlo antes de comprometerse a usar Xcode:

1. Haz un git Status en tu carpeta. Debería ver que los cambios por etapas son correctos:

renombrado: Project / OldName.h -> Project / NewName.h renombrado: Project / OldName.m -> Project / NewName.m

1. hacer commit -m 'cambio de nombre'

Luego regrese a XCode y verá que la insignia cambió de A a M y se guarda para confirmar cambios adicionales al usar xcode ahora.