Git Notes Gitの最高なのに不遇な機能とは？

コピーされるかどうかは設定できるよ。デフォルトでamendとrebaseではコピーされるようになってる。
詳しいことはgit-configのnotes.rewriteを見るといいよ。

いや、デフォルトじゃコピーされないよ。
notes.rewrite.amendとnotes.rewrite.rebaseがtrueでも、どのNotesを書き換えるか指定するnotes.rewriteRefも必要で、これにはデフォルト値がないんだ。
全部のNotesに適用したいならglob指定すればいけるけどね。

あー、警告サンキュー！Gitのドキュメントにはrefs/notes/commitsってデフォルトのcommit Notesを有効にするって書いてるけど、なんでこれがデフォルトじゃないんだろ？そもそも、なんでNotesの書き換えがデフォルトでオフになってるわけ？

俺、10年くらいGit使ってるのにGit Notesなんて知らなかったよ。クールだね！
著者が言ってる「forgeにコードレビューのメタデータをGitの中にオフラインで置けるようにしてくれ」ってのは、GitHubみたいな商業的なforgeには響かないだろうね。
だって、Gitリポジトリの価値の多くはGitHubみたいなforgeにロックインされてるわけじゃん？自分たちの価値をコモディティ化するわけないよ。GitHubを責めてるわけじゃなくて、商業ビジネスなら当然だよね。

その機能を差別化ポイントとして提供する新しいサービスが出てくれば、他の競合も追いつくために（その機能を）また追加するかもね。

見つけた関連イシューはこれだけ→https://codeberg.org/forgejo/forgejo/issues/6385
たぶん誰も提起してないからじゃない？

ニワトリと卵みたいだよね．ほとんどのプロバイダーがサポートしてないからあまり知られてないし、知られてないからサポートするプレッシャーもかからない．

Git notesが役立つのは、コミットした後で、みんなが見れるようにテキストを追加したい時だけだね．Acked-Byとかメーリングリストの議論リンクは良い例じゃないと思う．これらはコミットする時には分かってるだろうし．コミットメッセージは長さ無制限だから、forgeでの議論全部そこに入れられるしね．より良いユースケースは、後でrevertされたコミットにnoteを追加することかな．

よくある失敗は、直してないバグを直したと自慢するコミットメッセージとか、自分の修正で発生した新たなバグを一つのバグに結びつけることだね．自分が変わってるのかもしれないけど、何のためにそのコードが書かれたかを思い出すために注釈さえ見ない同僚が多すぎるんだ．彼らはとにかくやってみて、誰も問題の原因を自分に結びつけないことを願ってる．
でも、バグが直るのを待ち焦がれていた怒った顧客に対応して、そのバグがすぐに再発するのを経験すると、バグ修正についてはもっと慎重になるかもね．
複数のバグを一度に直すにはrefactorが必要なことが多いし、refactorは新しい機能の機会やパフォーマンス向上につながることもよくあるんだ．

＞Acked-Byとかメーリングリストの議論リンクは良い例じゃないと思う．これらはコミットする時には分かってるだろうし．
コミットに関する議論（レビュー）や承認は、コミットが作られる前に起こるわけないだろ．
＞より良いユースケースは、後でrevertされたコミットにnoteを追加することかな．
このユースケースにはコミットメッセージの方が向いてるよ．git blameすると、そのファイルの最新の変更が表示されるんだ．もしあるコミットが別のコミットからの変更をrevertしたら、古いコミットをrevertする新しいコミットがblameに表示されるからね．

＞コミットに関する議論（レビュー）や承認は、コミットが作られる前に起こるわけないだろ．
フィーチャーブランチでのコミット前には起こらないけど、メインの開発ブランチにマージする前には起こり得るよ．レビューが終わったフィーチャーブランチからの変更を統合するためにrebaseやmerge commitが頻繁に必要になることを考えると、この種の情報をマージ前に追加（あるいは必須にする）できない理由が分からないね．

rebaseの履歴を破壊する問題は、それだけで長文の愚痴になるね．

それはgitのUIの問題で、隠されたコミット（rebase前）を見つけにくくしてるんだ．コミットは破壊されてなくて、隠されてるだけだよ．Jujutsu CLIは、このUIの問題を直してくれてるから良いね．

それだけじゃない．gitには隠されたrebase前のコミットとrebase後のコミットの間に内部的なリンクがないみたいで、それが後続のコミットをそのrebaseをまたいでコピーする能力を損なってるんだ．
うん、rebaseをまたいで後続のコミットを移動するのは避けるべきだって言われてるけど、それを避けるべき理由は、gitがそれがすごく苦手だからなんだよね．

Rebaseってさ、git logできれいな履歴を見せたいから使われることもあるんだよね。GitのUIの問題を回避するのにさ。

この意見には完全に disagree できないな。Feature branch ではしょっちゅう commit するけど、それを main に全部含めたくないんだ。Rebase で review 前後に history をきれいに整理するんだよ。開発中の exact history を残すのはダメだと思うな。Git の UI は最悪だけどね。History をいじるのが問題じゃなくて、UI の悪さが根本原因だと思うよ。

自分の repository では好きにすればいいけど、public にしたら別。Push されたら、もうみんなが pulling してるって考えるべきだよ。Rebase で history 変えたら、新しい branch 作ったのと同じ。Git は decentralized な system だから、Bitcoin みたいに pushed commit は final なんだ。Merge commits が混乱を解決するやり方だよ。

Git の使い方について fundamental に disagree だね。Public repo だからって、tool がサポートしてるからって、全ての branch を永久に残す必要はないと思う。もし confusing なら、それは他の人が public feature branches を publish することで何か intent を伝えてると誤解してるからじゃないかな。

これが Git の history を壊す behavior に対する俺の core complaint だよ。Git は clean history を望んでるみたいだけど、共同作業した history を変えると awful behavior になる。これは fundamental flaw だね。Git は real な history を better に使うか、history modification に対応する better な automation や mapping concepts が必要だよ。

Git は clean history を望んでないよ。ただ DAG 構造で commit を保存して、lots of freedom を与えてるだけ。UI は notoriously terrible だから、presentation の complain は justified だろうね。Merge commits だけできれいな branch を作って presentation layer にすればいい。Mutable なのは distributed system では problem だしね、CAP theorem の通り。

Git の lots of features が history rewriting を accommodate してないように感じるのが problem だね。Comment 変えたり squash したりすると hash が変わるから、’hey is commit X in the history of both branches A and B’ を check する useful な ability が break する。Merge や rebase で conflict が起きるのも worse だよ。History rewriting action の proper な synced graph があれば、better な responses を提供できるはず。

Yep、君の言うことには disagree しないよ。History rewriting を防ぐ workflow に stick する cost を払っても、merge commits なしで clean history を持つのは still worth it だと思ってる。でも、これは personal preference の問題だし、team の consistent workflow が more important だよね。今は merge commits を使う team で働いてるけど、慣れるのに time がかかってるよ。

もっと詳しく教えて？俺は rebase を history destruction/obscuration を避けるために使ってるんだけど。Squash のこと？もしそうなら agree だよ。

Basically、commit comments や grouping together related commits を tweak すると hash が変わるんだよ。これが、’hey is commit X in the history of both branches A and B’ を check する git の useful な ability を break するんだ。Rebase on merge とか squash on merge が impractical になるのもこれ。Git は history rewriting を love するのに properly accommodate してないんだよ。In-repo objects で rebased commits と predecessors の関係を reify すれば better な response ができるはずだよ。

Ah, Gitの歴史破壊について知ってるよ。マージの時に他人のコミットをコッソリ変えて、バグをそいつのせいにできるズル技もあるんだ。昔、実際にやった奴を捕まえたことがあるよ。Git blameの履歴と実際のコードが食い違ってたからバレたんだ。Git notesとは関係ない話かもね。

Rebaseは新しい履歴を作って古いのは捨てるから、歴史破壊の一種だよ。コミットは差分じゃなくてリポジトリ全体のスナップショットなんだ。だからRebaseで古いコミットも残るけど、参照されなきゃガベージコレクションで消えるよ。

squashにもちゃんと使い道はあるさ。例えば、簡単なtypo直しとかね。直前のコミットとまとめてスッキリさせたい時とかに便利だよ。

君はコミットをアトム＝indivisible（不可分）なものとして捉えてるみたいだけど、Linuxみたいなパッチベースの開発だとちょっと違うんだ。多くの人は3-way mergeしかやらないけど、Linuxみたいな開発は違う。間違った3-way mergeを直すのを冗談で“5-way merge”って呼んだりするよ。

それ、どういう意味？Gitはコミットをatomic（変更不可能）として扱うから、atoms（indivisible、不可分）だよ。パッチとは関係ないと思うんだけど、どういうことか詳しく教えてくれない？

この人が俺より上手く説明してるよ。見てみて。
https://news.ycombinator.com/item?id=44355218

コミットメッセージって、ハッシュ値に影響するの？それともタグみたいに本体とは別扱いなの？

うん、コミットメッセージはハッシュ値に影響するよ。

俺、今の仕事でGit notesをかなり使ってるんだ。最初はコードレビューの記録とかに使ってみたんだけど、コミットにチケットとの連携、インフラの制約、障害対応のリンクとかを全部メモしてる。これのおかげでSlackとかJiraを探しまわなくて済むようになったよ。規模が大きくなると、GitHubとかのプラットフォームのUIってそんなにいらないんだなって気づく。ビルドの再現性ってよく言うけど、コミットの意図の再現性も大事だよね。Git notesはまさにそこから始まるのかも。

それってコミットメッセージにするべきじゃない？それとも、「このコミットがバグ#123を引き起こした」みたいに将来に紐付けるのが目的？

ハハ、ちょっと待って。長いコミットメッセージ（一行以上の）を最後まで全部読むの？僕的には、コミットメッセージはツイート、Git Notesはブログ記事って感じ。

僕の仕事ではバグで数億円かかることがあるから、長いコミットメッセージは読むよ。長いのも書くし。同僚にももっと長いコミットメッセージを書いてほしいと思ってる。

僕もだよ。ほとんどの場合、コミットメッセージは10行以上で、変更は+-1行だったりする。GitHubでホスティングして、Issue Trackerで変更を管理してるんだけど、GitHubのUIがコミットメッセージのMarkdownをレンダリングしないのがすごく嫌なんだよね。みんなすごく詳しく丁寧にフォーマットして書いてるのに、Issue TrackerにMarkdownで完璧に表示されるように、コミットメッセージの同期を工夫しないといけなかった。

もしコミットメッセージを読まないだろうって思うなら、どうしてNotesは読むと思うの？

コミットメッセージに情報を追加する方が、もっとシンプルに思えるな。Gitには読む時にコミットメッセージをトリミングするオプション (–oneline) もあるし。

これはUIの問題だよ、知識不足じゃない。GitHubのUIがNotesを表示したら、すぐにもっと使われるようになるはず。

うん、GitHubがNotesをサポートしてくれたらいいのにね。

記事で説明されてる通り、GitHubは過去にNotesをサポートしてたんだよ。このリンク見て。
https://github.blog/news-insights/git-notes-display/

なぜGitHubがNotesの表示をやめたのかは記事には書いてないね。

Gitってさ、bisectとかreflogとかpickaxeとか、知られてないけど超便利な機能いっぱいあるんだよ。みんなGoogle Driveみたいにしか使ってないから、もったいないんだよね。

Git notesって、Jiraみたいな別のプロジェクト管理ツール使うなら要らない機能だよね。Unix哲学みたいに、Gitは一つのことだけちゃんとやればいいんだと思うよ。

Notes使うプロジェクト管理ツールならIDE連携はしやすいかもね。でもNotesって、設定とか手がかかるのがダメなんだよな。デフォルトでONになって、pull/pushで勝手に同期されるくらいじゃないと、みんな使わないよ。

プロジェクト管理ツール使ってても、Git notesは使える場面あるんだよ。開発者しか見ない情報とか、上の目標のための元データとかね。

俺はツールの多くの機能は、マジで困った時だけ使う。そういう時パッとやると感謝されるんだけど、普段からツールを汚されるのは嫌なんだよな。
ファイルを間違って名前変更してGit履歴壊すとか。こういう規律は大事なんだって説明するの難しいよね。

俺がさっき挙げた機能（bisectとか）を他の奴らに教えたら、もっと早く知りたかった！ってすぐ使い始めたんだよね。だから、機能盛りだくさんすぎるツールもあるけど、Gitの場合は違うと思うよ。

記事に挙がる機能は知ってると思ってたけど、pickaxeってやつは初耳！なんだそれ？俺もまだまだだな。

pickaxeはGitコマンドじゃなくて、git logの-Sとか-Gっていうオプションのことだよ。git-blameより便利だって話は、このウェビナーで見れるよ→https://nofluffjuststuff.com/webinar/142/level_up_your_git_g…

pickaxeって基本的にはそのオプションのことだけど、もしかしたら古いgit-blameのコマンドエイリアスでもあったらしいよ。