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 ...
También tiene algunas seguridades integradas. –
Gracias @CharlesBailey - ¿Git considera los archivos newNameFile y oldNameFile como diferentes? En caso afirmativo, ¿qué sucede si queremos fusionarlos? Supongamos que ramificamos un proyecto de una hormiga en la rama A y creamos la Rama B y luego mavenizamos los proyectos en B. Los nombres de los archivos son los mismos, pero se ponen diferentes caminos a medida que cambia la estructura del proyecto. Supongamos que ambas ramas crecieron durante un tiempo en paralelo. En algún momento, si queremos fusionar los proyectos, ¿cómo sabrá git que es el mismo archivo que acaba de renombrar su ruta?(si "git mv" == "git add + git rm") – Rose
Supongo que es lo mismo con un 99.9999% de probabilidad. Obviamente, la autodetección podría salir mal si tiene, por ejemplo, múltiples archivos con el mismo nombre y/o el mismo contenido. – osa