Quel est le but de git-mv?

Question

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

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

Answer 1

 git mv oldname newname
 

est juste un raccourci pour:

 mv oldname newname
git add newname
git rm oldname
 

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

Answer 2

De la GitFaq officielle :

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

Answer 3

Git est juste d'essayer de deviner ce que vous essayez de faire. C'est faire de chaque tentative de préserver intacte l'histoire. Bien sûr, il n'est pas parfait. Donc, git mv vous permet d'être explicite avec votre intention et à éviter certaines erreurs.

Considérons cet exemple. Départ avec un vide repo,

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 s'agit-il?

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

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

    change

et puis

$ git log --follow c

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

    change

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

    initial commit

Maintenant, essayez à la place (n'oubliez pas de supprimer l' .git le dossier 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

So far So good:

# 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: seulement --follow montre la totalité de l'histoire.

---

Maintenant, être prudent avec les renommer, comme chaque option peut encore 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 <orshansk@gmail.com>
Date:   Sat Oct 12 00:35:58 2013 -0400

    second move

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

    initial b

Par contraste 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 <orshansk@gmail.com>
Date:   Sat Oct 12 00:37:13 2013 -0400

    both moves at the same time

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

    initial a

Ups... Maintenant l'histoire remonte à l' initiale d'un au lieu de l' initiale b, ce qui est faux. Alors, quand nous avons fait deux coups à la fois, Git est devenu confus et n'a pas suivi les changements correctement. Par ailleurs, dans mes expériences, la même chose s'est produite lorsque j'ai supprimé/les fichiers créés au lieu d'utiliser git mv. Procéder avec soin; vous avez été prévenu...

Answer 4

Comme le dit @Charles, git mv est un raccourci.

La vraie question ici est "D'autres contrôles de source (par exemple Subversion et Perforce) traitent les renames de fichiers spécialement Pourquoi pas Git?"

Linus explique à http://permalink.gmane.org/gmane.comp.version-control.git/217

Answer 5

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

Depuis la découverte d' git add -p (git add du mode patch; voir http://git-scm.com/docs/git-add), j'aime l'utiliser pour examiner les modifications que j'ai ajouter à l'index. Ainsi, mon travail devient (1) travail sur le code, (2) l'examen et l'ajouter à l'index, (3) s'engager.

Comment est - git mv ? Si le transfert d'un fichier directement ensuite à l'aide d' git rm et git add, tous les changements sont ajoutés à l'index, et l'utilisation de git diff de visualiser les modifications apportées est moins facile (avant de s'engager). À l'aide de git mv, cependant, ajoute le nouveau chemin d'accès à l'index, mais pas les modifications apportées au fichier, permettant ainsi d' git diff et git add -p à travailler comme d'habitude.