36

私は git-format-patch と git-am を使用して、あるリポジトリから別のリポジトリに変更を適用しています。ファイル構造は同じですが、私が適用しているリポジトリにいくつかの変更があり、ほとんどのパッチがいくつかのハンクに失敗します。しかし、ほとんどのパッチ ハンクは、行番号が多少あいまいな状態で適用されます。

git-am apply私が非常に厳密に解釈できる限り、これらのパッチはすべて完全に拒否されます。

だから私のワークフローは

$ git am ../the-patch.patch
# Fails because the patch doesn't apply cleanly
$ patch -p1 < ../the-patch.patch
# Applies most of the hunks, leaves .rej files for the ones that conflict
# Fix the conflicting hunks manually
$ git am --continue

コマンド ライン パッチを実行する必要がなく、am コマンドの一部として実行できればよいのですが。

フラグを指定して実行すると、--rejectファイル内のすべてのハンクを含む .rej ファイルが作成されるように見えますが、これは私が望んでいるものではありません。

--3wayフラグを指定して実行すると失敗します

fatal: sha1 information is lacking or useless (the-file.java).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.

これは、これが基づいていた変更セットが、マージ先のリポジトリにないためだと思います。

git-am applyraw patch コマンドのようにあいまい一致でパッチを作成し、失敗したハンクを含む .rej ファイルのみを作成する方法はありますか?

4

6 に答える 6

2

私があなたを正しく理解していれば、コード フォーム 1 のレポを別のレポにマージしようとしていて、コードの一部で失敗しています。その後、手動で修正し、今後はエラーなしでマージしたいと考えています。

この場合、使用する必要がありますgit rerere

比較的長い存続期間のトピック ブランチを使用するワークフローでは、開発者は、トピック ブランチが完了する (「リリース」ブランチにマージされるか、送信されて上流に受け入れられる) まで、同じ競合を何度も解決する必要がある場合があります。

このコマンドは、最初の手動マージで競合する自動マージ結果と対応するハンド解決結果を記録し、以前に記録されたハンド解決を対応する自動マージ結果に適用することにより、このプロセスで開発者を支援します。

git config --global rerere.enabled true
于 2016-01-06T21:56:17.957 に答える
1

@Nick Desaulniers が上記にリンクしているスレッドに基づいて、-3オプションをgit apply/amに使用すると、少なくともある程度は機能するようです。

たとえば、次のエラーで失敗したパッチの出力は次のgit applyとおりです。

$ git apply < patch_file.patch error: patch failed: file_being_patched.txt:489 error: file_being_patched.txt: patch does not apply $ git apply -3 < patch_file.patch error: patch failed: file_being_patched.txt:489 Falling back to three-way merge... Applied patch to 'file_being_patched.txt' cleanly.

それでもエラーが発生するのは残念です (スクリプトで出力を解析するのがより困難です)。patchファズのレベルは多くの場合、パッチ コマンドが失敗する可能性があるかどうかの良い指標であるため、ファズのレベルがどのようなものであったかはわかりません。間違えました。

于 2017-06-22T12:29:17.450 に答える
0

これには、機能要求の構成があります。そのことを確認するには、Git メーリング リスト (git@vger.kernel.org) に参加し、しばらく読んで文化を理解してください。同時に、上記で提案したビフォア/アフター ドキュメントを準備して、自分の考えを明確にします。

準備ができたら、リストに自己紹介し、アイデアを簡潔に説明します。あなたの提案の効果が他の手段で十分に達成できるかどうかという質問に必ず答えてください。励ましの言葉を受け取った場合は、より詳細なドキュメントをフォローアップしてください。提案からのフィードバックが手元にあるので、機能要求のバグの送信を続行するか、検討用のパッチを作成する立場に立つことができます。

于 2015-07-20T20:29:23.473 に答える