“Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.”

Why did Douglas Crockford remove comments from JSON? - Hashnode
https://hashnode.com/post/why-did-douglas-crockford-remove-comments-from-json-cir97ves31fxu2i536bp7u37f

“I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.”

Why did Douglas Crockford remove comments from JSON? - Hashnode
https://hashnode.com/post/why-did-douglas-crockford-remove-comments-from-json-cir97ves31fxu2i536bp7u37f

tig で SEGV するんだ

大人の科学として買った初音ミクの声出るスタイロフォン、どこに仕舞ったんだっけ……

わりと前からハイテクな気はする

このアカウントは、notestockで公開設定になっていません。

journalctl とかでよくみるログは severity でメッセージ全体が黄や赤で色ついてる印象だったけど、たしかに Rust とかでよくみるやつは行頭の serverity 示す文字列だけ色つきだったりするな

@kb10uy なるほどね

@kb10uy severity で色つけるとき、メッセージ全体に色つけがちな気がする（とおもったけどエラーログとかじゃなくて interactive shell のプロンプトとかだったらしらない……

@miwpayou0808

文字数揃えるの諦めるほうがはやそう

git bisect は自動テスト用意して、そのテスト通るかどうかで通らなくなった commit を二分探索で突き止めるまで自動でやるコマンドです。自動テスト用意できなさそうなときはユーザーが手動で ok なコミットかどうかを入力する。

@ponkotuy 市場で指摘されたりテレメトリ解析でバグってることがわなりました、じゃあ具体的にどこでそのバグ要因が入ったのでしょう、となったときに、git bisect とかやれば二分探索で原因のコミットはひとまず判明するとして、PR まるごと revert してもひとまずはよいけど、原因コミットが綺麗な粒度になってないとコミットの中の具体的に何がバグ要因なのかがパッと見つけ辛くなると思う。色々な変更が絡んでいると特に

@ponkotuy 市場に出てから半年や数年して出てくるようなバグいくらでもあるよ、show stopper なバグではないけどタイミング問題点とかセキュリティ問題とかで地雷になってて顕在化してないやつ

@ponkotuy 責任取るのは自動化できることを手でやることではないですね……。
合流そのものが早くなるわけではないけど何かの issue に assign されたときどういう意図で変更されたかがたとえば VScode でマウスオーバーしたらサッと出てきたら変更のために手をつけていいところか悪いところかパッとわかってよい

@ponkotuy どの PR で入れ込んだ変更でデグレてそうかエスパーできなければ結局聞きにいった相手も自分の PR や commit の履歴漁ることになるのでそれは git blame したり git bisect したりでできることを手動でやってるだけなのでは感

@ponkotuy それ聞きにいって相手の工数奪わなくても git bisect なら半自動化できるじゃないですか、というのと、後からプロジェクト入る人はそれ git log とかみてもよくわからんし close されてる PR や issue を半年 ROM ってから開発入ります！になっても困るし、とかってなりません？

@ponkotuy それ逆にバグってるぽいときの犯人探し（犯人というか犯 commit）どうやってるの……

ビルド通らなくてもいいブランチ切ってそこに対して何回か PR して、ビルド通せるようになったらブランチごと main なり develop なりに PR 出す、とかやるかなあ

このアカウントは、notestockで公開設定になっていません。

@ponkotuy PR の merge commit 相手にまるっと revert commit つくるか commit 単体に revert commit つくるのかは場合によりけりで使い分ければよいだけなのでは。あとどちらかというと git blame や git bisect が便利になるほうが重要

たぶんだいたいおなじ

@ponkotuy PR も当然意味ある単位に整理するけど、たとえば複数モジュール跨った変更であっちのモジュールの変更はそのままだけど、みたいな場合もあるかもしれないじゃん。PR はあくまである issue に対する patch series で、commit はその series のうちのひとつだし

git rebase --autosquash は整理した歴史つくったあとにまだ入れたかった変更を追加するときに fixup! つけた commit つくってやったりする

@ponkotuy 後からリグレッションとかわかったときに revert しようとしたとき、残したい変更が残せないしそもそも git bisect で犯人探しもできない

わたしは autosave のつもりで git commit -a -m 'wip' を適宜やって、PR 出すときにまずすべての変更を 1 commit にしてから git reset HEAD~ して git 的な変更は一切なかったことにして、そこから git add -p で意味的にキレイに分割してる嘘の歴史をつくったりしますね……