it-swarm-eu.dev

Comment puis-je "blâmer" une ligne supprimée?

git blame est idéal pour les lignes modifiées et ajoutées, mais comment puis-je savoir quand une ligne qui existait dans une précédente validation spécifique a finalement été supprimée. Je pense bisect mais j'espérais quelque chose de plus pratique.

[avant de vous demander: dans le cas, je viens de faire un git log -p et j'ai recherché la ligne de code et (a) un idiot avait juste supprimé la ligne vitale dans le commit précédent et ( b) j'étais cet idiot]

457
Malvolio

Si vous connaissez le contenu de la ligne, il s'agit d'un cas d'utilisation idéal pour:

git log -S <string> path/to/file

qui vous montre les commits qui introduisent ou suppriment une instance de cette chaîne. Il y a aussi le -G<regex> qui fait la même chose avec les expressions régulières! Voir man git-log et recherchez les options -G et -S ou pioche (nom convivial de ces fonctions) pour plus d'informations.

L'option -S est également mentionnée dans l'en-tête de la page de manuel git-blame, dans la section description, où elle donne un exemple utilisant git log -S....

581
Cascabel

Je pense que ce que tu veux vraiment, c'est

git blame --reverse START..END filename

De la page de manuel :

Parcourez l’histoire vers l’avant plutôt que vers l’avant. Au lieu de montrer la révision dans laquelle une ligne est apparue, cela montre la dernière révision dans laquelle une ligne a existé. Cela nécessite une plage de révision telle que START..END où le chemin à blâmer existe dans START.

Avec git blame reverse, vous pouvez trouver le dernier commit dans lequel la ligne est apparue. Vous devez toujours obtenir le commit qui suit.

Vous pouvez utiliser la commande suivante pour afficher un journal git inversé. Le premier commit affiché sera la dernière fois que cette ligne apparaîtra, et le prochain commit le sera quand il sera modifié ou supprimé.

git log --reverse --ancestry-path COMMIT^..master
126
Chronial

Juste pour compléter la réponse de Cascabel

git log --full-history -S <string> path/to/file

J'ai eu le même problème que mentionné ici mais il s'est avéré que la ligne était manquante car un commit de fusion d'une branche avait été annulé puis réintégré dans celle-ci, supprimant ainsi la ligne en question. Le drapeau --full-history empêche de passer ces commits.

9
estani

git blame --reverse peut vous amener close à l'endroit où la ligne est supprimée. Mais en réalité ne ne pointe pas vers la révision où la ligne est supprimée. Il pointe vers la dernière révision où la ligne était présente . Ensuite, si la révision suivante est un commit simple, vous avez de la chance et vous obtenez la révision de suppression. OTOH, si la révision suivante est un fusion commit, alors les choses peuvent devenir un peu sauvages. Dans le cadre de l’effort de création de difflame , j’ai abordé ce problème même si vous avez déjà installé python sur votre ordinateur et que vous êtes déjà connecté. prêt à essayer, alors n'attendez plus et laissez-moi savoir comment ça se passe.

https://github.com/eantoranz/difflame

8
eftshift0