Quel est le but de git-mv?

D'après ce que je comprends, Git n'a pas vraiment besoin de suivre les opérations de renommage / déplacement / copie de fichiers , alors quel est le véritable objectif de git mv ? La page de manuel n'est pas spécialement descriptive ...

Est-ce obsolète? Est-ce une commande interne, non destinée à être utilisée par des utilisateurs réguliers?

git mv oldname newname

est juste un raccourci pour:

mv oldname newname
git add newname
git rm oldname

c'est-à-dire qu'il met automatiquement à jour l'index pour les anciens et les nouveaux chemins.

Du GitFaq officiel :

Git a une commande renommer git mv, mais c'est juste une commodité. L'effet ne se distingue pas de la suppression du fichier et de l'ajout d'un autre avec un nom différent et le même contenu

Git essaie juste de deviner pour vous ce que vous essayez de faire. Il s'efforce de préserver une histoire ininterrompue. Bien sûr, ce n'est pas parfait. git mvVous permet donc d'être explicite avec votre intention et d'éviter certaines erreurs.

Considérez cet exemple. En commençant par un repo vide,

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

Résultat:

# 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")

La détection automatique a échoué :( Ou est-ce le cas?

$ 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

puis

$ 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

Essayez maintenant à la place (n'oubliez pas de supprimer le .gitdossier lors de l'expérimentation):

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

Jusqu'ici tout va bien:

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


git mv b a
git status

Maintenant, personne n'est parfait:

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

Vraiment? Mais bien sûr...

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

... et le résultat est le même que ci-dessus: --followaffiche uniquement l'historique complet.

Maintenant, soyez prudent avec le changement de nom, car l'une ou l'autre option peut toujours produire des effets étranges . Exemple:

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

Comparez-le avec:

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

Résultat:

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 ... Maintenant, l'histoire revient à l' initiale a au lieu de l' initiale b , ce qui est faux. Donc, quand nous avons fait deux mouvements à la fois, Git est devenu confus et n'a pas suivi correctement les changements. Soit dit en passant, dans mes expériences, la même chose s'est produite lorsque j'ai supprimé / créé des fichiers au lieu de les utiliser git mv. Procédez avec soin; tu as été prévenu...

Comme le dit @Charles, git mvc'est un raccourci.

La vraie question ici est "Les autres systèmes de contrôle de version (par exemple Subversion et Perforce) traitent spécialement les renommages de fichiers. Pourquoi Git ne fonctionne-t-il pas?"

Linus explique à http://permalink.gmane.org/gmane.comp.version-control.git/217 avec tact caractéristique:

Veuillez arrêter cette merde de "fichiers de suivi". Git suit exactement ce qui compte, à savoir les "collections de fichiers". Rien d'autre n'est pertinent, et même penser qu'il est pertinent ne fait que limiter votre vision du monde. Remarquez comment la notion de CVS "annoter" finit toujours inévitablement par limiter la façon dont les gens l'utilisent. Je pense que c'est une merde totalement inutile, et j'ai décrit quelque chose qui, je pense, est un million de fois plus utile, et tout est tombé exactement parce que je ne limite pas ma pensée au mauvais modèle du monde.

Il y a une autre utilisation que j'ai pour git mv pas mentionnée ci-dessus.

Depuis la découverte git add -p(mode patch de git add; voir http://git-scm.com/docs/git-add ), j'aime l'utiliser pour revoir les modifications lorsque je les ajoute à l'index. Ainsi mon workflow devient (1) travailler sur du code, (2) réviser et ajouter à l'index, (3) valider.

Comment git mvs'intègre-t-il? Si vous déplacez un fichier directement, puis en utilisant git rmet git add, toutes les modifications sont ajoutées à l'index, et l'utilisation de git diff pour afficher les modifications est moins facile (avant de valider). L' utilisation git mv, cependant, ajoute le nouveau chemin d' accès à l'index , mais pas les modifications apportées au fichier, permettant ainsi git diffet git add -pau travail comme d' habitude.

Il existe un cas de niche où git mvreste très utile: lorsque vous souhaitez modifier la casse d'un nom de fichier sur un système de fichiers insensible à la casse. APFS (mac) et NTFS (windows) sont, par défaut, insensibles à la casse (mais en respectant la casse).

greg.kindel le mentionne dans un commentaire sur la réponse de CB Bailey.

Supposons que vous travaillez sur un Mac et que votre fichier soit Mytest.txtgéré par git. Vous voulez changer le nom du fichier en MyTest.txt.

Tu pourrais essayer:

$ mv Mytest.txt MyTest.txt
overwrite MyTest.txt? (y/n [n]) y
$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

Oh cher. Git ne reconnaît pas que le fichier a été modifié.

Vous pouvez contourner ce problème en renommant complètement le fichier, puis en le renommant:

$ mv Mytest.txt temp.txt
$ git rm Mytest.txt
rm 'Mytest.txt'
$ mv temp.txt MyTest.txt
$ git add MyTest.txt 
$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    Mytest.txt -> MyTest.txt

Hourra!

Ou vous pourriez vous épargner tout cela en utilisant git mv:

$ git mv Mytest.txt MyTest.txt
$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    Mytest.txt -> MyTest.txt