web-dev-qa-db-ja.com

空白/行末を無視したチェリーピック

git cherry-pickにrenormalizeマージ戦略を使用するように指示する方法はありますか？ -Xオプションが機能しているかどうかわかりません。

あるタイプの行末を想定しているように見えるコミットがたくさんあり、別のタイプを想定しているブランチにそれらを適用しようとしています。楽しい時間を過ごしていない...

linuxgitline-endings
24
hwjp

したがって、完全を期すために、答えはignore-all-spaceマージ戦略は仕事をします：

git cherry-pick -X ignore-all-space <commit-id>

これにより、ファイルの末尾がUNIXのバージョンである場合など、ファイルの末尾がUNIXの場合に簡単にコミットを選択できます。

37
hwjp

この質問はかなり古いことは知っていますが、これはグーグルの「gitcherry-pickignorewhitespace」からの最初の投稿であるためこの回答を追加します。

-X ignore-all-spaceは正常に機能しますが、スペースを無視しないチェリーピックオ​​プションで競合が発生した場合は、コミットを手動で確認する必要があります。 （または、チェリーピッキング中に--no-commitを使用し、それを確認するにはgit diff --stagedを使用します）

場合によっては、-X ignore-all-spaceオプションは問題ないように見えますが、一部のインデントが間違っています。

たとえば、次のように、ignore-all-spaceを使用していないときに、先頭の空白とマージの競合が発生したとします。

    Change from theirs, Indent level 1(no conflict with/out whitespace)
<<<<< HEAD
Indent level 0
=====
    Indent level 1 without any code change
>>>>> cherry-picked commit

この場合、-X ignore-all-spaceは競合を示していませんが、実際のコミットは次のようになります。

    Change from theirs, indent level 1
Indent level 0

ここで起こったことは、ロジックが変更されたため、前のコード（レベル0のインデント）がレベル1にインデントされるはずですが、ignore-all-spaceオプションを指定したためではありません。

したがって、tl; drは次のようになります。

  1. -X ignore-all-spaceオプションは、先頭の空白も無視します。これは、Pythonなどの状況や言語では問題になる可能性があります。
  2. したがって、そのオプションを使用した後、手動で確認する必要があります。
  3. 代わりに-X ignore-space-at-eolを使用し、主要な空白の競合を手動で処理してください。

ただし、これらのオプションがこの問題の主な理由ではないため、読むのをやめないでください。この問題の核心は、全員が同じ空白の規則に固執しているわけではないということです。

先頭と末尾の空白の場合：リンティングツール、IDE、または同じルールに準拠するものを使用します。これはOS固有のものではなく、チームが他の開発者の生活を楽にするために何らかの努力を払う場合に従うことができます。

Eolの変更の場合：これはOS固有ですが、幸いなことにgitはマルチプラットフォーム開発環境用のcore.autocrlfとcore.eolをサポートしています。詳細については、 git-scm を参照してください。

3
ik1ne