tl; dr:
Linux ces dernières années n'est pas si putain. La «valeur F» maximale était de 25, concentrée sur un seul fichier.
Il fut un temps où c'était une tradition Linux, mais j'ai l'impression que ça s'est calmé récemment. Pourtant, il y a des références dans la commande fuck et les listes de diffusion.
Alors quel est l'événement qui m'a impressionné? Cette fois, le nombre d'apparitions du mot F dans le journal de validation et son code source diff est défini comme ** valeur F , et le commit avec la valeur F la plus élevée ( le commit le plus F-valué **) est défini. J'ai décidé de le chercher.
(Notez que le commit avec le mot F supprimé reçoit également une valeur F élevée car c'est le nombre d'apparitions dans le code source diff)
git show tous les commitsRécemment, j'ai utilisé CMake au lieu du script shell, donc je l'ai également écrit dans CMake cette fois-ci.
Fondamentalement, git rev-list HEAD affiche une liste de commits, la classe dans les 3 premiers caractères 000 -- fff du hachage de commit (= 16 ** 3 = 4096 divisions) et construit la cible. Et laissez ninja s'exécuter en parallèle.
Dans le référentiel Linux (https://github.com/torvalds/linux)
$ git rev-list HEAD | wc -l
897506
Il semble qu'il y ait environ 900 000 commits qui mènent à HEAD. Cependant, ** Notez que ce référentiel ne contient pas de commits pré-Git **.
La valeur F d'un commit est généralement calculée par grep.
$ git show -p -w HEAD | grep -ci fuck
0
La valeur F de HEAD est naturellement zéro, et c'est 1 dans le commit https://github.com/torvalds/linux/commit/4b550488f894c899aa54dc935c8fee47bca2b7df qui modifie les lignes périphériques du code source incluant F-word.
$ git show -p -w 4b550488f894c899aa54dc935c8fee47bca2b7df | grep -ci fuck
1
Il faut du temps pour utiliser grep tel quel, il est donc préférable d'utiliser un outil de grep à grande vitesse tel que ripgrep (https://github.com/BurntSushi/ripgrep) pour tout trouver ensemble.
$ rg -ci fuck
fa/76/fa7662aad7dc033a61ff2f705c33cbb301d0552d.diff:1
f4/db/f4dbc4c20f05ccf6986b0de429f7552b21a1b362.diff:1
51/53/51533b615e605d86154ec1b4e585c8ca1b0b15b7.diff:1
29/57/2957c9e61ee9c37e7ebf2c8acab03e073fe942fd.diff:2
36/5b/365bff806e9faba000fb4956c7486fbf3a746d96.diff:1
5b/5f/5b5f9560354dc5a3a27ce57a86aec6b98531ee21.diff:1
96/39/963945bf93e46b9bf71a07bf9c78183e0f57733a.diff:1
b2/e1/b2e1b30290539b344cbaff0d9da38012e03aa347.diff:2
Le commit avec la valeur F la plus élevée dans le référentiel git Linux est le ** premier commit **, c'est-à-dire le code source Linux lui-même lorsqu'il a été migré vers git, avec une valeur de ** imposant 56 **.
$ git show -p -w 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | grep -ci fuck
56
Comme prévu, cet engagement pourrait être intronisé au Temple de la renommée.
Le top 3 des autres commits sont
** Tous les mêmes fichiers ** ʻarch / mips / pci / ops-bridge.c` ** traitement **. Ce fichier peut être appelé ** F-King ** dans l'histoire de Linux.
Ce fichier a été créé en séparant le fichier pci-ip27.c avec un commit avec une valeur F de 24. En regardant le fichier original, nous pouvons voir que ce fichier était assez F depuis le début lorsque Linux a commencé à être géré par git.
--https: //github.com/torvalds/linux/blob/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2/arch/mips/pci/pci-ip27.c#L90 - contient déjà de nombreux mots F au moment du premier commit de Git
Inversement, les fichiers avec de telles valeurs F exceptionnelles ne sont pas créés après la migration git, on peut donc dire que Linux n'est pas F au moins en termes de code source.
Au fait, le code avec la valeur F la plus élevée dans le code source actuel du noyau Linux est drivers / net / ethernet / sun / sunhme.c, et sa valeur est ** seulement 2 **. La valeur F actuelle de ʻops-bridge.c` mentionnée ci-dessus est zéro et a été effacée par un commit avec une valeur F de 12.
cleaned up language in arch/mips/pci/ops-bridge.c
Ce commit lui-même a été fait en 2019, mais en 2018, il existe une proposition de correctif https://lkml.org/lkml/2018/12/1/105 qui est difficile à comprendre, même avec un commit avec une valeur F de 25 Essayer d'améliorer un peu la grammaire https://github.com/torvalds/linux/commit/686957e71d34beffe2b29cf5fb2e05025972020b.
Il s'avère que le noyau Linux en tant que logiciel n'a pas une valeur F très élevée, du moins après la migration Git. Il semble y avoir place à l'enquête avant le passage à Git, mais il semble que l'impression de Hack soit due aux activités humaines.
Vous aurez peut-être besoin d'un meilleur indicateur que la valeur F. Par exemple, plutôt que de définir la valeur F pour chaque validation, un autre indicateur tel que la durée de vie du mot F peut être considéré.
Dans cette évaluation de la valeur F, nous ne pourrions prêter attention qu'à ʻops-bridge.c. Surtout lors de l'extraction de lignes de diff, il est vulnérable au mouvement de ligne et surestime la valeur F dans commit. Cependant, jusqu'à présent, il n'existe aucun format qui puisse bien exprimer le mouvement au-delà du fichier. En plus de diff, git blame considère également le mouvement de ligne, et vous pouvez utiliser -M ou -C` pour effectuer l'extraction.
Recommended Posts