Comment empêcher git de penser que j'ai fait un renommage ?

Question

J'ai deux fichiers index.html y template.html . J'ai déménagé la plupart des index.html en template.html et maintenant git pense que j'ai fait un renommage quand j'ajoute les deux fichiers. Est-il possible d'éviter cela dans des cas spécifiques ?

Answer 1

Pourquoi Git pense que vos fichiers sont des copies

Pistes de Git contenu et non des noms de fichiers. En conséquence, si deux fichiers ont un contenu substantiellement similaire, git pensera que vous avez copié ou renommé le fichier. Si vous lisez git-log(1), vous apprendrez :

L'indice de similitude est le pourcentage de lignes inchangées et l'indice de dissimilarité est le pourcentage de lignes modifiées. Il s'agit d'un nombre entier arrondi à la baisse, suivi d'un signe de pourcentage. La valeur de l'indice de similarité de 100 % est donc réservée à deux fichiers égaux, tandis qu'une dissimilarité de 100 % signifie qu'aucune ligne de l'ancien fichier ne s'est retrouvée dans le nouveau.

Ainsi, en supposant que votre indice de similarité soit de 100%, git pensera qu'il s'agit d'une copie. Le mieux est d'ajouter un message de log ou une note (voir git-notes(1) pour plus d'informations) pour expliquer ce qui se passe si vous pensez que git ne fait pas ce qu'il faut.

Ajustement de l'indice de similitude

Vous pouvez également essayer d'ajuster les valeurs utilisées par git pour considérer que quelque chose est une copie ou un renommage. Le manuel de git-log(1) dit :

-M[<n>], --find-renames[=<n>]

If generating diffs, detect and report renames for each commit. For
following files across renames while traversing history, see --follow. If
n is specified, it is a threshold on the similarity index (i.e. amount
of addition/deletions compared to the file’s size). For example, -M90%
means git should consider a delete/add pair to be a rename if more than
90% of the file hasn’t changed.

-C[<n>], --find-copies[=<n>]    

Detect copies as well as renames. See also --find-copies-harder.
If n is specified, it has the same meaning as for -M<n>.

Encore une fois, cela ne vous aidera pas si les fichiers sont en grande partie similaires, mais vous pouvez certainement utiliser ces valeurs pour ajuster comment Les copies ou les renommages ne sont pas considérés comme des copies ou des renommages. Votre kilométrage peut varier.

Answer 2

Il existe une réponse "acceptée", mais elle ne donne aucune indication sur la manière de répondre à la question.

La bonne réponse, d'après git-log(1) et git-diff(1), est la suivante :

   --no-renames
       Turn off rename detection, even when the configuration
       file gives the default to do so.

Answer 3

Si vous êtes dans un moment juste avant un commit et que vous vous sentez mal que git soit devenu fou, alors annulez simplement l'ajout du fichier ambigu que git pensait que vous aviez renommé, effectuez un commit, puis ajoutez à nouveau le fichier ambigu et faites un commit :

git reset ambiguous_file_git_thought_you_renamed
git commit
git add ambiguous_file_git_thought_you_renamed
git commit

Cela a fonctionné pour moi.

Vérifier qu'aucun changement de nom n'a eu lieu :

git diff --name-status -C HEAD^^ HEAD
M       ambiguous_file_git_thought_you_renamed
M       original_file

"M" au début signifie modifié, "R" signifie renommé. Remarquez qu'il n'y a pas de Renommé ici.

Answer 4

Si vous avez modifié les fichiers A, B et C, et supprimé les fichiers D, E et F, il est possible que git pense que D a été renommé en A, ou quelque chose de similaire.

La solution la plus simple consiste à diviser les modifications et les suppressions de fichiers en deux livraisons.