問題タブ [diff3]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
1178 参照

merge - 複数のパッチを適用して累積された変更を取得する

base.hs同じプログラム ( foo.hsbar.hs、 ) の異なる拡張バージョンを作成するために使用する基本ソースファイルがありbaz.hsます。ここで、変更されたすべてのバージョンのパッチ ファイルを作成したいと考えていますが、すべての拡張機能を含むプログラムを取得するには、パッチを蓄積する必要があります。

base.hs

foo.hs (基本的に同じファイルであることに注意してください)

bar.hs

baz.hs

=>

拡張された.hs

差分 + パッチ?

diffおよびユーティリティについては認識していpatchますが、問題は、複数のパッチを適用すると、それらが互いに打ち消し合うことです (したがって、 が得られますbaz.hs)。

機能しない

コンビディフ?

私も知ってcombinediffいますが、これはパッチが順番に適用された場合にのみ機能するため、base_foo.hs.

diff3?

差分 + パッチ - 置換の代わりに合計diff3がユーティリティ (パッケージ)を参照していますpatchutilsが、必要な動作が機能していないように見えます。さらに、これが複数のパッチでどのように役立つかわかりません。

機能しない

(ここでのアイデアは、空のファイルからの差分を結合することです)

機能しない

(明らかに、3つのバージョンすべてを含む大きな競合ファイルが生成されます)

その他?

git のような SCM のマージ ツールを使用するというアイデアもありましたが、それらはコミットでのみ使用できるようですが、私のファイルはバージョン管理されていません。

私の現在の解決策は、コードスニペットを介して挿入することですperl -pi -eが、かなり面倒でエラーが発生しやすいです。

0 投票する
1 に答える
112 参照

version-control - VCS 理論 - マージ: 再帰的リビジョン マージまたは 3 リビジョン マージ?

VCS のマージの可能性について理論的な質問があります。多くの VCS が 3 つのリビジョン マージを使用していることを知っています。これは、共通の祖先である「私の」リビジョンと「あなたの」リビジョンです。私はそれらがどのように機能するかを知っています。

別の代替案である再帰的なリビジョンのマージについて考えましたが、Google では見つかりませんでした。「あなたはアメリカを見つけました!」あなたが考えるかもしれません。Git が再帰マージを使用することは知っています。しかし、Git が再帰マージを使用する理由は、十字型マージのためです。

私は通常のケース、非交差マージについて話しています。

たとえば、共通の祖先 A と分岐 1 および 2 があります。

前に述べたように、A は共通の祖先なので、B と B' の親です。

G と G' をブランチ 1 にマージします。Git と Mercurial が使用する一般的な方法は、diff3 です。

これは、O(1) である 3 つのバージョンのみを計算することによってマージを計算します。

私が考えた代替アルゴリズムは O(n) です。

  1. 最初に祖先に最も近いリビジョンをマージします。

  2. 結果をブランチ 1 の次に近いリビジョンとマージします

  3. 結果をブランチ 2 の次に近いリビジョンとマージします (残っている場合)

  4. ブランチ 1 にリビジョンが残っている場合は、ステップ 2 まで (ループ内で) 繰り返します。

上記の例では、次のようになります。

  1. B と B' をマージする

  2. 結果を C とマージする

  3. 結果を C' とマージする

  4. 結果を D とマージする

  5. 等々...

私が解決できなかった質問は、従来の 3 つのリビジョンのマージよりも、の方法がより安全で正確であるというケースはありますか?

私のやり方は、従来のやり方が引き起こす衝突を避けることができますか?

私のやり方は、伝統的なやり方では起こらない新たな対立を生み出すことができますか?

私の方法の競合は「本当の」競合ではありませんか? (伝統的なやり方では起こらない)

0 投票する
1 に答える
65 参照

git - Git では、ファイルではなく変更を比較してマージする方法 (またはツール) はありますか?

Git では、標準のマージ アルゴリズムを使用して、2 つのブランチのファイルの最終的な状態を比較できます。つまり、両方のブランチでその時点までにどのような変更があったかを覚えておくか、推測する必要があります。

.gitconfig で merge conflictstyle=diff3 を設定すると、共通の祖先が表示されるので役立ちます。ただし、頭の中で差分を作成する必要があります。つまり、さまざまなセクションをスキャンして、祖先とブランチ A の間、および祖先とブランチ B の間で何が変更されたかを把握し、最後に両方を祖先に適用するか、一方を適用する必要があります。ブランチの他の変更。

私のためにこれを行うツールはありますか?あるブランチで発生した変更を他のブランチで発生した変更と比較できるようにしたいと考えています。理想的には、このツールは、マージしようとしている変更のコミット メッセージも表示するので、意図を推測する必要はありません。

0 投票する
4 に答える
16541 参照

git - diff3 を git のデフォルトの conflictstyle にする必要がありますか?

最近、私は diff3 を有効にしました。競合を解決するのがはるかに簡単になりました。

以前は、ログをチェックして、人々がマージを行う理由を確認する必要がありました。しかし、diff3 を使用すると、情報はすべて 1 か所に表示されます。

そのことから、結果が「これは本当に便利です」であることが簡単にわかります。

diff3 に欠点があるのだろうか?git のデフォルトの動作ではないのはなぜですか?

0 投票する
1 に答える
5353 参照

git - Git - diff3 Conflict Style - 一時的なマージ ブランチ

merge.conflictStyleに設定してマージを行っていdiff3ます。通常、これにより、4 セットの文字で区切られた 3 つのセクションが挿入されます。

MergeのGit ドキュメントでは、これらの記号が単純なケースで何を意味するかを明確に説明しています (後述)。

通常の差分 3:

ただし、余分な行が多数あるため、より複雑な結果が得られます (以下を参照)。現在マージしているコミットの祖先に多数のマージを行ったという事実と関係があると感じていますが、余分な行が何を意味するのかわかりません。また、この動作に関するドキュメントが見つからないようです。

これが私が得たものです(もちろん、コードのアイデンティティを保護するために編集されています)。

(マージしようとしているコミットのコードには競合マーカーがないため、それは答えではありません。)

この質問は同じことを尋ねていると思いますが、答えは、質問者がタイトルですでに知っているものとしてすでに示したdiff3と関係があることを説明していません。その質問を2回編集しようとしましたが、拒否されたので、もう一度質問します。

0 投票する
0 に答える
79 参照

svn - SVN - バイナリ ファイルに外部 diff3 を使用するには?

テキスト ファイルとバイナリ ファイルを操作する外部の mydiff3.exe がいくつかあります。

私のsvnコマンドラインは

これは、テキスト ファイルではうまく機能します (svn は、更新プロセスを通じて競合するファイルごとに mydiff3.exe を呼び出します)、バイナリ ファイルでは、svn は mydiff3.exe をスキップし、内部コマンドライン メニューを表示します。

バイナリファイルの --diff3-cmd mydiff3.exeを受け入れるように svn に指示するにはどうすればよいですか?

RTFM ( svn red-bookの diff3-cmd外部ツール) は役に立ちません。

UPD : 動作は mime-type に依存するという言及がありますが、どこで設定するかは明確ではありません。

0 投票する
1 に答える
18 参照

diff - ウィキの翻訳を維持する

プロジェクトのいくつかの翻訳をウィキで維持しようとしています。ウィキは翻訳をサポートしていませんが、テキスト ファイルを使用してインポート/エクスポートできます。簡単にするために、ドキュメント内のすべてのファイルが単純なテキスト ファイルであると考えてみましょう。

こんなふうになります:

  1. 私はウィキ文書を英語で書いています。
  2. 私はそれをダウンロードします(うまくいけば、ツールがそれをしてくれます)。
  3. 新しいファイルは、他の翻訳用のディレクトリにコピーされます (新しいファイルなので、まだ翻訳されていません)。
  4. 翻訳者は新しい wiki ページを自分の言語に翻訳します。その時までにまだディスク上にあり、まだtxtファイルにあります。
  5. 必要に応じて、翻訳者は新しく翻訳されたファイルを Web 上にアップロードします。

ここまでは順調ですね。

  1. 新しい機能を開発し、英語の wiki ページを修正しました。
  2. ダウンロードします。
  3. 翻訳されたバージョンを更新します...待ってください、既に存在します。ファイルを書き込んで、翻訳者がステップ 4 で行ったすべてを削除することはできません!

したがって、次のことを考慮して部分的に翻訳されたファイルを作成する方法が必要です。

  1. ドキュメントが翻訳されたときのファイル (英語)。
  2. 同時に同じファイルのファイル (どの言語でも)。
  3. 新しく変更したファイル (英語)。

diff3 の良い使用例のようです。しかし、diff3 はそれほど変更されたファイルを処理することをあまり好みません。確かに、両方の英語版を比較することはできますが、翻訳版は違いすぎて、あちこちで競合が発生します。

私の翻訳へのアプローチは少し奇妙かもしれません。私は他の戦略を見つけようとしましたが、商業的な代替案に溺れてしまいました。

私の説明がお役に立てば幸いです。もう少し詳しく教えてください。