CRDTは「何か」ではないことに注意してね。CRDTの論文は、最終的に一貫性のあるレプリケーションメカニズムについて考えたり分析したりする方法を提供しているだけ。だからCRDTは「導入された」わけではなく、「レプリケーションを議論するCRDTの方法」があるだけ。CRDTの論文で説明されている具体的なメカニズムは、非常に古くて、数十年前から広く使われているものなんだ。つまり、最終的な一貫性を実装しているもの（Gitを含む）は「CRDTを使っている」ということになる。

2007年にブラムが、「君のCausal Treeアルゴリズムはweaveのバリアントだよ」って言ってくれたんだ。それは大体合ってる。ここ20年で、weave系のアルゴリズムはかなり増えたよ。2020年の記事では、彼らのファミリーポートレートを作ることにイントロを捧げたんだ。https://arxiv.org/abs/2002.09511 これ、別の記事にできたかもね。

Pijulのことは聞いたことがなかったな。最初の検索で https://github.com/8l/pijul に行ったけど、11年間更新されてなかった。でも、実はそれは誤解で、公式リポジトリの https://nest.pijul.com/pijul/pijul は先月コミットがあったんだ。... もちろん、Pijulは開発にPijulを使っていて、GitやGitHubは使ってないからね！

変な趣味があるんだ。年に一回くらい、pijulマニュアルの理論ページ[0]を見に行って、TeXのフォーマットが直ってるか確認するんだよね。パッチを保存するためのより良い、より堅実なモデルが売りなら、プロジェクトに興味がある人が理解しやすいようにするのが普通だと思うんだけど。好奇心旺盛な読者に対して、マニュアルの第一印象を気にしないのは本当に変だよ。今、実験を始めてから約6年経ってる。約2年前（4年くらい前）に、Pijul Nestに行って[1]この問題を報告したこともあるんだ。ローカルでこの問題を直す方法の説明はもらったけど、なぜかその修正は公のバージョンには実装されてなかったんだよね。実験の進捗については、また1年後に報告するつもりだよ。[0] https://pijul.org/manual/theory.html [1] https://nest.pijul.com/pijul/manual/discussions/46

Pijul使ってる？たまに'pijul pull -a'をpijulソースツリーにやるんだけど、コンフリクトが出るんだ（自分のローカル作業はなし）。トラッキングアップデートプルの方法ってあるのかな？見当たらなかったから、リポジトリを捨てて再クローンしてる。そこでの進捗を追うのに何がうまくいってる？

これ

重複があるマージはユーザーにフラグが立てられるって書いてあるけど、実際にはgitのデフォルトの違い以上のものではないと思う。衝突の警告を出して、両側を無条件に結合するだけのgitのバージョンも作れるんじゃないかな。

これについては触れられてるよね。実際に失敗しないわけじゃないけど…重要なのは、変更が互いに触れ合うときに対立としてフラグが立てられるべきだってこと。そうすることで、実際には失敗しないシステムの上に、情報を提供する対立の表示が得られるんだ。

同意するけど、Gitが時々苦しむ他の場面、たとえば同じdiffだけど親が違う二つのコミットを同等とみなすべきかどうか、これにこのアプローチが役立つか気になる。一般的には、そういうコミットは同じとはみなせないよね。あるブランチが別のファイルでフリップしたブール値をひっくり返すコミットを考えてみて。だけど、リベースされたブランチのように、同等とみなすべき一般的なケースもある。例えば、git branch -d BRANCHがリベースされたBRANCHがマージされたときに成功すべきだと決めるのにCRDTアプローチは役立つのかな？

力不足なテキストマージの混乱に頼って、そんな問題を見つけるべきなの？スマートなマージではコードの問題じゃないマージの問題に反応するし、マージが成功しても深い問題を引き起こすものを見逃すこともある。マージ後の構文チェックの方がその目的にはいいよ。そして、すぐにでも: 意図を保持したエージェントベースのサニティチェック – 論理的に完全な結果ファイルで、マージツールの雑音なしで動作する。行の重なりがあるときや、目的の交差のより意味のあるヒントがあるときには、さらに高い強度で行われるかもしれないね。

確かに。成功したマージでもコンパイルできないコードになることが多いよね。ちなみに、AIツールがマージコンフリクト（特にリベース）をうまく処理できないのも、同じ根本的な理由で苦労してる。

これが提示されている方法の理解としては、マージがワークフローを「ブロック」しないってことだね。Gitではマージコンフリクトはマージの失敗だけど、このアイデアではマージコンフリクトは存在するけどマージは成功する。未解決のコンフリクトでコミットできるから、後でコンフリクト解決を先延ばしにできるんだ。jjもこれをやってると思う？技術的には、コミットにコンフリクトマーカーを含めることもできるけど、あんまり好まれないと思う。

数百行のよく考えられたPythonで、厳しいハックに頼らずにできることは本当にすごいよね。JS界隈ではleft-pad事件とかで文句言われてるけど、正直Pythonエコシステムはもっと小さなパッケージがあった方がいいと思う。責任感のある人が、ポイントを主張したり人工的な指標を膨らませたりしないで、提案していく必要があるね。

簡単に使える三分割マージにはp4mergeがいいよね。Gitの他の問題と同じように、マージが辛いのは、ひどいネイティブUXデザインが原因だと思う。Git自体に根本的な問題があるわけじゃないよ。

p4mergeを使わなくても、Gitのmerge.conflictStyleを"diff3"か"zdiff3"に設定できるよ（https://git-scm.com/docs/git-config#Documentation/git-config...）。そうすると、Gitのコンフリクトマーカーにベースバージョンも表示されるんだ。>>>右側 この設定にすると、生のコンフリクトマーカーを読む開発者は、Manyanaのコンフリクトマーカーが提供するのと同じ情報を推測できるんだよね。つまり、右側がログ行を追加したってこと。

なぜその問題を解決するためにVCSを切り替える必要があるのか理解できない。なぜか、この件に関してはほとんどの人が問題について考えていると思っているけど、実際にはあまり考えていないみたい。最近、人気のある尊敬されているポッドキャストのエピソードを聞いたんだけど、そこにゲストが出てきてバージョン管理システムについて話してたんだ。自分たちの新しいシステムを宣伝するために来てたんだけど、彼らの業界が他のソフトウェア開発のサブフィールドとどう違うのか、なぜ新しいアプローチが必要なのかを語ってた。彼らは思慮深いけど、現状に対して苛立っているように見えたし、考慮に値する問題を挙げてたけど、ほとんど高レベルの主張にとどまってた。でも、エピソードの半分くらい、30分か45分経った頃に、彼らが新しいVCSの詳細に入ろうと準備しているときに、Gitの能力と比較する軽いコメントをしたんだ。Gitがファイルのリビジョン間で「diff」をどう保存するかに関するアプローチ/デザインを参照してね。驚いたよ。そんな立場の人が、数ヶ月（数年）かけて設計、実装して、プレゼンテーションをするために話し回るプロジェクトを始める前に、ほんの少しのリサーチもしていないなんて、本当にNIHの熟知したストレインがまだ生きていることを強調してるよ。今の時代、NPM/Cargo/PyPI/何でもいいけど、問題を解決すると主張している既存のパッケージがないと、自分で数十行のコードを書くことに抵抗を感じる人が多いのにね。

それは別の投稿にする価値があるね！（HTMLにレンダリングすることをお勧めするよ）でも、「物足りない」ってのはコーエンの投稿の価値の一部だと思う。パラダイムシフトを広めたいなら、小さくて消化しやすい部分に分けるのが助けになるよ。

これってビットトレントを作ったブラム・コーエン？このページには意外と情報が少ないね。

CRDTが衝突を起こさないってことで、みんながそれを全ての問題の解決策だって言ってるけど、実際には衝突が必然的にある問題もあるんだよね。そういうのはCRDTでは全く表現できないか、衝突解決の方法が考えられた場合よりも悪くなることもある。例えば、同時に編集された文字が交互に表示されるマルチプレイヤーテキストエディタとか。

前はマージよりもリベースをよく使ってたけど、年を重ねるごとに考え方が変わってきた。メインからフィーチャーブランチへのマージは全然問題ないし、リベースよりも簡単だよ。フィーチャーブランチが完成したら、最後にメインからフィーチャーブランチをマージして、フィーチャーブランチをメインにスカッシュコミットでマージする。リモートからブランチを更新する時は、常にプルリベースをして、シンプルなプルからマージコミットを避けてる。これが99.99%の確率でうまくいくのは、何を変更したかとリモートの変更が明らかだから。開発ブランチでプロジェクトをやってる時は、フィーチャーブランチをメインじゃなくてdevから派生したものとして扱う。この場合、devをフィーチャーブランチにマージして、フィーチャーブランチをスカッシュコミットでdevにマージして、最後にメインをdevに、devをメインにマージする。こうすれば、devとメインにはいくつかのマージコミットができるけど、緊急修正みたいなことがメインで起こった時だけだよ。リベースを常に使う問題は、最終結果だけじゃなくて、途中の全てのコミットで衝突を解決しなきゃいけないこと。これって、実際には使われないコミットのために余計な手間がかかるし、履歴をめちゃくちゃにすることもある。こう考えてみて：1. メインからfooブランチを作成。2. メインに緊急コミットXを追加。3. fooでフィーチャー作業をしてコミットA、B、Cを作成。フィーチャーが完成した。4. fooをメインからリベースして、XがAの前にあることによる衝突を解決しなきゃいけない。仮にそれがA、B、Cの全てと衝突したとしたら。5. その後、fooをメインにファストフォワードコミットでマージできる。XAやXABの状態でコードベースを実行したいとは思わないよね。XABCとして実行したいだけ。実際、XAやXABの状態でコードが動くかテストすることもないから、そのチェックポイントを持つ意味はほとんどない。気にするのは、これらの状態：何も起こる前のメイン、Xが追加されたメイン、そしてXABCを持つメイン。git blameを使うのは、AとBのコミットを個別に見る唯一の時かもしれないけど、その有用性は限られてるから、やる価値はあまりない。実際、ファストフォワードコミットだけを望むなら、古いバージョンのコードを取り出すためにほとんど何もしていない可能性が高い。自分にこう問いかけてみて：「もしメインのgit履歴を全部削除して、現在の状態とフィーチャーブランチだけが残ったら、プロダクションシステムに何か悪いことが起こる？」もし起こらないなら、実際にはgitのほとんどの機能を使ってないってことだよ（それは良いことだけど）。

「作業の単位」って言った時、どの作業の単位を指してるの？リベースの問題は、一つのスナップショットのセットを取り、それを別のセットの上に再生することだから、結局二つの「同等な」作業の単位ができちゃう。実際にはそれらは「同じ」なんだけど、もし「作業」が変更を意味するなら、Gitは明らかに二つの異なる履歴を示すことになる。これはPijulと対照的で、Pijulでは変更がパッチで、交換可能なんだ。全体のセットを適用しても、パッチの適用順序に関係なく結果は同じであるべきなんだ。これが「作業の単位」だと理解できるのは、"孤立"で適用したり元に戻したりできるもの。私の目には他のものはごちゃごちゃしてるけど、他の人には秩序があるのかもしれない。コードで定義されたソフトウェアシステムが、各パッチが「原子的」でフィーチャーや修正などを表現できる独立したパッチのセットで表現できるといいんだけど、Gitではそれはグラフの中ではほぼ不可能だよね。もちろん、フィーチャーに属するコミットのセットをチェリーピックしたりリベースしたりすることはできるけど、なんでそんなことをするの？

ファイルを編集する前に、バージョン管理システムが他の誰かがすでに変更を加えたか、現在作業中であることを警告してくれたら、すごく便利だよね。大きなチームでは、この種の自動化が衝突を減らすだろうし、人間が同じファイルに触れないことに同意すれば、悪い衝突解決から生じる品質の後退も減るだろう。これで私のVSS時代を思い出させる（できれば思い出させないでほしいけど）。

ここでのミスマッチは、ほとんどの人が中央の目立つリモートリポジトリを使ってgitを利用していることから広がっているように見える。Gitは真の分散ビジョンで開発されたのにね。確かに、その真の分散というのは、最終的に何らかの「中央」リポジトリに到達した時にのみ完了するけど、私たちがやっていることとはかなり違う。

それには、非常に中央集権的なVCSが必要で、分散型のはダメだよ。Perforceはファイルをロックできるから、他の人が編集できなくなるんだ。もしファイル内でより細かいロックを実装したり、他のユーザーが編集のためにチェックアウトしようとしたときに警告を出したりしたら、まさに理想的なVCSになるだろうね。どうして、あるいはむしろ、なぜGitが事前に潜在的な競合について警告してくれるの？使い方としては、みんながリポジトリのローカルクローンを持っていて、異なる方向に進んでいる可能性があるのに。結局、誰かのローカルブランチからコミットをプルしたり、そこにプッシュしたりするのが前提だから、その言い回しなんだよね。同じ方向に協力して作業することが理にかなっていて、摩擦や痛みを避けるのは、使っている人間から自然に生まれた偶然の産物であって、ツールの設計に組み込まれているわけじゃない。俺たちは、Gitの可能性の中で最もバカバカしくて単純な部分、つまり中央の真実のソースを持つVCSとして使っているだけで、分散ワークロード向けに設計されたツールが持つ複雑さの負担を背負っているんだ。

うん、著者はイントロの段階で自分の主張をうまく伝えられてない。 > CRDTマージは定義上常に成功するので、従来の意味での衝突はない — 重要な洞察は、変更が互いに触れるときに衝突としてフラグを立てるべきだということで、実際には決して失敗しないシステムの上に情報的な衝突プレゼンテーションを提供してくれる。このプロジェクトはそれを解決している。明らかな矛盾がある。CRDTは定義上常に成功し、従来の意味での衝突はないから（言い換えれば）衝突する変更は衝突としてマークされる。えっと、他のソース管理でもそうじゃない？実際、答えを書いている間にそのイントロを再読してみて、AIが書いた匂いを感じ始めたよ。