LinuxでもっともF-wordなコミットを探す(git以降編)

# tl; dr:

近年のLinuxはそれほどファ●ックではない。最大の"F値"は25で、単一のファイルに集中していた。

# もくてき

ファッ●クと言えばLinuxの風物詩と言える時期もあったが、最近は落ちついてきた印象はある。それでも [`fuck` コマンド](https://github.com/nvbn/thefuck) やメーリングリスト等では言及は有る。

では、それを印象付けるような出来事としては何があったのだろうか。今回、コミットログおよびそのソースコードdiffにおけるF-wordの登場回数を **F 値** (F value) と定義し、最もF値の高いコミット(**the most F-valued commit**)を探してみることにした。

(ソースコードdiffにおける登場回数であるため、F-wordを削除したコミットも高いF値が与えられることに注意する)

# 全てのコミットを `git show` する

最近シェルスクリプト代わりにCMakeを使っているので今回もCMakeで書いた。

- https://github.com/okuoku/cmtask-gitexplode/tree/a88b50a45d5030cc17eb4072b296806636dcf603

基本的には `git rev-list HEAD` でコミットのリストを出力し、それをcommit hash先頭の3文字 `000` - `fff` に分類して(= 16**3 = 4096分割)ビルドターゲットとし、 `ninja` に並列実行させている。

Linuxのリポジトリ( https://github.com/torvalds/linux )では、

```
$ git rev-list HEAD | wc -l
897506
```

HEADに繋がるコミットは約90万コミットあるようだ。ただし、 **このリポジトリにはGit以前のコミットが含まれない事に注意する** 。

# コミットのF値を求める

コミットのF値は普通にgrepで求められる。

```
$ git show -p -w HEAD | grep -ci fuck
0
```

`HEAD` のF値は当然のごとくゼロ、F-wordを含むソースコードの周辺行を編集したコミット https://github.com/torvalds/linux/commit/4b550488f894c899aa54dc935c8fee47bca2b7df では1となる。

```
$ git show -p -w 4b550488f894c899aa54dc935c8fee47bca2b7df | grep -ci fuck
1
```

流石にgrepをそのまま使うと時間が掛かるので、ripgrep( https://github.com/BurntSushi/ripgrep )のような高速grepツールで纏めて求めるのが良い。

```
$ 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
```

# F値の高いコミット

LinuxのgitリポジトリでもっともF値が高いコミットは **最初のコミット** 、つまり、gitに移行したタイミングのLinuxソースコード自体で、その値は **堂々の56** となった。

- https://github.com/torvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

```
$ git show -p -w 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | grep -ci fuck
56
```

流石にこのコミットは殿堂入りとしても良いだろう。

そうでないコミットのtop3は、

- 25 https://github.com/torvalds/linux/commit/686957e71d34beffe2b29cf5fb2e05025972020b
- 24 https://github.com/torvalds/linux/commit/9e0c7afd0ec6e6d788df14270b2b1b8f21a384a8
- 12 https://github.com/torvalds/linux/commit/a44d924c81d43ddffc985aca14aeeaf1abd6dd22

**何と全部同じファイル** `arch/mips/pci/ops-bridge.c` **に対する処理** となっている。このファイルはLinuxの歴史における **F-キング** と言っても差し支えないだろう。

このファイルはF値24のコミットでファイル `pci-ip27.c` から分割されて作られた。元のファイルを見ると、このファイルはLinuxがgitで管理され始めた当初からかなりFだったことがわかる。

- https://github.com/torvalds/linux/blob/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2/arch/mips/pci/pci-ip27.c#L90 - Gitの最初のコミット時点で既に多くのF-wordを含む

逆に言えば、このように突出したF値を持つファイルはgit移行後には作られていないということになるわけで、少くともソースコードの面ではあまりLinuxはFでは無いと言えるだろう。

ちなみに現時点のLinuxカーネルソースコードで最大のF値を持つコードは `drivers/net/ethernet/sun/sunhme.c` で、その値は **たったの2** となっている。先に挙げた `ops-bridge.c` の現在のF値はゼロであり、F値 12 のコミットで一掃されている。

- https://github.com/torvalds/linux/commit/a44d924c81d43ddffc985aca14aeeaf1abd6dd22

> cleaned up language in arch/mips/pci/ops-bridge.c

このコミット自体は2019年に行われているが、2018年にはわかりづらい表現のパッチ提案 https://lkml.org/lkml/2018/12/1/105 が存在し、F値25のコミットでも多少の文法改善を試みている https://github.com/torvalds/linux/commit/686957e71d34beffe2b29cf5fb2e05025972020b 。

# かんそう

少くともGit移行後に限れば、ソフトウェアとしてのLinuxカーネルはあまり高いF値を持っていないことがわかった。Git移行以前については調査の余地はあると見られるが、フ●ァックの印象は人間活動によるものと言ってよさそうだ。

F値よりも良い指標が必要かもしれない。例えば、F値をコミット毎に定義するよりも、F-wordの生存期間といった別の指標が考えられる。

今回のF値評価では、 `ops-bridge.c` にしか注目できなかった。特にdiff行の抽出では行の移動に弱く、コミットにおけるF値を過大評価してしまう。しかし、今のところファイルを超えた移動を良く表現できるフォーマットが存在しない。`git blame` ではdiff以外に行の移動についても考察しており `-M` や `-C` で抽出を行わせることができる。