素数を探求するプロジェクト「GIMPS」は10月21日（現地時間）、今まで人類が見つけた数値の中で最も大きい素数「2^136億27万9841-1」（136億27万9841個の2を掛け合わせ、1を引いた値）を見つけたと発表した。これまで記録していた最大の素数よりも、1600万桁以上大きい値。十進数で表現した場合、桁数は4102万4320桁に及ぶという。
“最も大きい素数”更新 「2^136億27万9841-1」元NVIDIA社員が発見 文字に起こすと4000万字超え - ITmedia NEWS
今回、52番目のメルセンヌ素数を見つけたのは、米カリフォルニア州サンノゼ在住の研究者であるルーク・デュラントさん。デュラントさんは米NVIDIAの元社員で、23年10月ごろからGIMPSに参加。研究のため、多数のGPUサーバ上でGIMPSの解析ソフトウェア一式を実行、維持するためのインフラストラクチャを開発したという。
“最も大きい素数”更新 「2^136億27万9841-1」元NVIDIA社員が発見 文字に起こすと4000万字超え - ITmedia NEWS
これにより1年間の検証を続ける中で、デュラントさんは新たな素数を発見。発見当時、デュラントさんが築いた「クラウドスーパーコンピュータ」ともいえる解析環境は、17カ国にまたがる24のデータセンター地域による数千台のGPUサーバで構成されていたという。第三者も検証を行ったところ、24年10月12日に新たな素数であることを正式に確認できたとしている。
“最も大きい素数”更新 「2^136億27万9841-1」元NVIDIA社員が発見 文字に起こすと4000万字超え - ITmedia NEWS
⇧ どうやって検証したのかしら？
何にせよ、最早、圧倒的な物量が無いと「素数」発見の作業は成り立たないということですかな...
やはり、お金の力が全てというか、「金の弾丸」で解決することが多いのですかな...
「銀の弾丸」は出て来ないってことですかね。
git revertとgit reset
まずは、公式のドキュメントを確認してみる。
■git revert
NAME
git-revert - Revert some existing commits
https://www.atlassian.com/git/tutorials/undoing-changes/git-revert
DESCRIPTION
Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).
https://www.atlassian.com/git/tutorials/undoing-changes/git-revert
■git reset
DESCRIPTION
In the first three forms, copy entries from <tree-ish> to the index. In the last form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <tree-ish>/<commit> defaults to HEAD in all forms.
うむ、分からん。
Atlassianが図解してくれているのだけど、
⇧ 左から右にコミット履歴が積み上げられているのだとすると、
| No | コマンド | コミット履歴 | 内容 | |
|---|---|---|---|---|
| 1 | git revert | 追加される | 指定したコミットの状態に戻す | |
| 2 | git reset | --soft | 追加されない | HEADを移動するが、変更はステージングエリアに残る |
| --mixed | 追加されない | （デフォルト）: HEADを移動し、変更は作業ディレクトリに残るが、ステージングエリアはクリアされる | ||
| --hard | 追加されない | HEADを移動し、変更はすべて消去される（作業ディレクトリも変更される） | ||
⇧ ということらしい。
git revertってcommit messageは元の状態に戻らないよね
で、「git revert」が、コミットを追加してくれてしまうということで、「commit message」が金太郎飴の如く、上書きされてしまいますと...
どういうことかというと、「Oxidized」というRuby製のライブラリがありまして、内部で「Rugged」なるライブラリを使っているようなのですが、あろうことか、Gitリポジトリで管理されていたファイルを根こそぎ削除してくれちゃったわけですよ。
正確には、git pushの前のコミットまでを、「Oxidized」が処理していたので、
- ローカルのbare repositoryが上書きされた
- コミット前の処理でファイルの削除が行われた
のどちらかが為されたのかなと。
どちらにしろ、
- Rubyの知見が無い
- ドキュメントが整備されていない「Oxidized」のライブラリを雰囲気で利用するしかない
- 「Oxidized」における「Rugged」の実装が不明
という、三重苦といった極度のストレスが常態化している状況において、「心的外傷後ストレス障害（PTSD：PostTraumaticStressDisorder）」を発症しそうであり、この時点で、発狂しかねないんだけど、開発用の環境のGitリポジトリであったのが不幸中の幸いと言いますか。
で、ネットの情報とかだと、『「git revert」を使うべきである』という意見が多いのだけど、誰も『「commit message」は元に戻せない』という点については言及してくれていないんですな...
仮に、100ファイル削除された後に、「git push」されたとして、「git revert」した場合、100ファイル全てについて「git revert」時の「commit message」で上書きされてしまい、元の「commit message」が無かったことになってしまうのである。
これは、そういうものとして、受け入れるしか無いのかしら？
「git revert」で、ファイルは元の状態に戻すことができるけど、「commit message」を元の状態に戻すことはできないと。
「git revert」による「commit message」を見る度に、『やらかしてしまった烙印』を背負っていけという感じなんですかね...
まぁ、自分がやらかしたならまだしも、ドキュメントが整備されておらず、どういった利用方法が正しいのかよく分からんライブラリがやらかしてくれたということが、理不尽極まりない気がして致し方ないんよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
