コーディング標準としてB&Dの代わりにK&Rを使用して、Gitとの競合が最も少ないことをどのように示すことができますか?

c# coding-style git merge-conflict-resolution
コーディング標準としてB&Dの代わりにK&Rを使用して、Gitとの競合が最も少ないことをどのように示すことができますか?

Gitは賢く、履歴の変更を「追跡」して、マージを簡単にし、自動マージをさらに強化します。 競合は、変更の前後で変更されていない行で表されます。 K&Rを使用すると、B&Dの場合のように「\ {」のみが含まれるあいまいな行は取得されません。 変更を囲む線に関して、Gitのコンテキスト感度の制限をどのようにテストしますか?

必要のないかもしれない競合の解決を避けたい。 しかし、K&Rとそれがもたらす追加のコンテキストに切り替えることで、潜在的な競合の数をテストする方法が必要です。

これまでのところ、Gitはあまりにもスマートなので、些細な例にだまされることはありません。

任意の助けは大歓迎です。 前もって感謝します。

  2  2


ベストアンサー

したがって、これはこれまでの証拠として私が見つけた最も近いものです。 + http://git.661346.n2.nabble.com/Bram-Cohen-speaks-up-about-patience-diff-td2277041.html

この電子メールでは、Gitの「忍耐」アルゴリズムの目的について議論しています。 その中でBramは、大きなパッチを含むかなり複雑なマージの場合にのみ、解決するのが難しい厄介な競合を余計なマッチングラインが作成する方法を説明しています。 言い換えれば、単純な不自然な例では、この動作を示すことができません。

彼は結果に影響を与えるEndのようなことにも言及していますが、それ自身の行に開始ブレースを配置すると、不必要な一致する行の数が増加し、これらの競合の可能性が大きくなる可能性があると推測することは理にかなっています。

これは鉄に覆われたものではないと思いますが、この理論にはある程度の信用があります。

_
したがって、「一意の行」は「重要でない行」の単純な言語間プロキシです。
_

私たちは基本的に、コンテキストを提供するはずの重要な行であると感じるものに一致しているので、この議論ではその引用が際立っていますが、ブレース自体は重要ではなく、コンテキストを提供しません。

2


あなた/あなたのチームが他のものを読みやすい標準を選択してください。 今日のソース管理システムの動作に関係なく、明日は動作が向上しますが、コードは長期間チェックインしたままになります。

0


K&RとB&Dの大規模な混合物を含むいくつかの大きなプロジェクト(200以上のコードファイル)があります。 リファクタリングに夢中な開発スタッフであり、「1日に数回」のリベース動作を行うGitで2年近く働いた後、コーディング標準の問題のために競合したことは一度もないと言っても過言ではありません。 したがって、どちらか、または両方、あるいはどちらも選択しないでください。 関係ありません。

0


タイトルとURLをコピーしました