¿Cuál es el propósito de git-mv?

Question

Por lo que entiendo, Git realmente no necesita rastrear archivo renombrar/mover/copiar operaciones, entonces ¿cuál es el verdadero propósito de git mv? La página de manual no es especialmente descriptiva ...

¿Está obsoleto? ¿Es un comando interno, no destinado a ser utilizado por usuarios regulares?

Answer 1

git mv oldname newname 

es sólo la abreviatura de:

mv oldname newname 
git add newname 
git rm oldname 

es decir, se actualiza el índice para los dos caminos antiguos y nuevos de forma automática.

Answer 2

Desde el official GitFaq:

Git tiene un comando de cambio de nombre git mv, pero eso es sólo una conveniencia. El efecto es indistinguible de la eliminación del archivo y la adición de otro con diferente nombre y el mismo contenido

Answer 3

Como dice @Charles, git mv es una taquigrafía.

La verdadera pregunta aquí es "Otros sistemas de control de versiones (por ejemplo, Subversion y Perforce) tratan especialmente los nombres de los archivos modificados. ¿Por qué Git no?"

Linus explica en http://permalink.gmane.org/gmane.comp.version-control.git/217 con tacto característico:

Por favor, deja este "archivos de la pista" porquería. Git rastrea exactamente lo que importa, a saber, "colecciones de archivos". Nada más es relevante, e incluso pensando que es relevante solo limita su visión del mundo. Observe cómo la noción de "anotar" de CVS siempre inevitablemente limita la forma en que las personas usan . Creo que es una porquería totalmente inútil, y describí algo que creo que es un millón de veces más útil, y todo se cayó exactamente porque no estoy limitando mi pensamiento al modelo incorrecto del mundo.

Answer 4

Git solo intenta adivinar lo que intenta hacer. Está haciendo todo lo posible para preservar la historia ininterrumpida. Por supuesto, no es perfecto. Entonces, git mv le permite ser explícito con su intención y evitar algunos errores.

Considere este ejemplo. A partir de un repo vacío,

git init 
echo "First" >a 
echo "Second" >b 
git add * 
git commit -m "initial commit" 
mv a c 
mv b a 
git status 

Resultado:

# On branch master 
# 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) 
# 
# modified: a 
# deleted: b 
# 
# Untracked files: 
# (use "git add <file>..." to include in what will be committed) 
# 
# c 
no changes added to commit (use "git add" and/or "git commit -a") 

detección automática no :( O lo hizo?

$ git add * 
$ git commit -m "change" 
$ git log c 

commit 0c5425be1121c20cc45df04734398dfbac689c39 
Author: Sergey Orshanskiy <*****@gmail.com> 
Date: Sat Oct 12 00:24:56 2013 -0400 

    change 

y luego

$ git log --follow c 

Author: Sergey Orshanskiy <*****@gmail.com> 
Date: Sat Oct 12 00:24:56 2013 -0400 

    change 

commit 50c2a4604a27be2a1f4b95399d5e0f96c3dbf70a 
Author: Sergey Orshanskiy <*****@gmail.com> 
Date: Sat Oct 12 00:24:45 2013 -0400 

    initial commit 

Ahora intenta lugar (recuerde que debe eliminar la carpeta .git al experimentar):

git init 
echo "First" >a 
echo "Second" >b 
git add * 
git commit -m "initial commit" 
git mv a c 
git status 

Hasta aquí todo bien:

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


git mv b a 
git status 

Ahora nobo dy es perfecto:

# On branch master 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
# modified: a 
# deleted: b 
# new file: c 
# 

¿Realmente? Pero, por supuesto ...

git add * 
git commit -m "change" 
git log c 
git log --follow c 

... y el resultado es el mismo que el anterior: sólo se --follow muestra el historial completo.

---

Ahora, tener cuidado con el cambio de nombre, como cualquiera de las opciones todavía puede producir efectos extraños. Ejemplo:

git init 
echo "First" >a 
git add a 
git commit -m "initial a" 
echo "Second" >b 
git add b 
git commit -m "initial b" 

git mv a c 
git commit -m "first move" 
git mv b a 
git commit -m "second move" 

git log --follow a 

commit 81b80f5690deec1864ebff294f875980216a059d 
Author: Sergey Orshanskiy <*****@gmail.com> 
Date: Sat Oct 12 00:35:58 2013 -0400 

    second move 

commit f284fba9dc8455295b1abdaae9cc6ee941b66e7f 
Author: Sergey Orshanskiy <*****@gmail.com> 
Date: Sat Oct 12 00:34:54 2013 -0400 

    initial b 

contraste con:

git init 
echo "First" >a 
git add a 
git commit -m "initial a" 
echo "Second" >b 
git add b 
git commit -m "initial b" 

git mv a c 
git mv b a 
git commit -m "both moves at the same time" 

git log --follow a 

Resultado:

commit 84bf29b01f32ea6b746857e0d8401654c4413ecd 
Author: Sergey Orshanskiy <*****@gmail.com> 
Date: Sat Oct 12 00:37:13 2013 -0400 

    both moves at the same time 

commit ec0de3c5358758ffda462913f6e6294731400455 
Author: Sergey Orshanskiy <*****@gmail.com> 
Date: Sat Oct 12 00:36:52 2013 -0400 

    initial a 

Ups ... Ahora la historia va de nuevo a sus iniciales en un lugar deinicial b, lo cual es incorrecto. Entonces, cuando hicimos dos movimientos a la vez, Git se confundió y no siguió los cambios correctamente. Por cierto, en mis experimentos sucedió lo mismo cuando borré/creé archivos en lugar de usar git mv. Proceda con cuidado; usted ha sido advertido ...

Answer 5

Hay otro uso que tengo para git mv no mencionado anteriormente.

Desde que descubrí git add -p (modo de parche de git add; consulte http://git-scm.com/docs/git-add), me gusta usarlo para revisar los cambios cuando los agrego al índice. Por lo tanto, mi flujo de trabajo se convierte en (1) trabajar en el código, (2) revisar y agregar al índice, (3) confirmar.

¿Cómo encaja git mv? Si se mueve un archivo directamente y luego usando git rm y git add, todos los cambios se agregan al índice, y usar git diff para ver los cambios es menos fácil (antes de confirmar). Sin embargo, al usar git mv, se agrega la nueva ruta al índice, pero no los cambios realizados en el archivo, lo que permite que git diff y git add -p funcionen de la forma habitual.