回答:
Gitはfilepermissionを追跡し、を使用してパッチを作成するときにアクセス許可の変更を公開しますgit diff -p。したがって、必要なのは次のとおりです。
ワンライナーとして:
git diff -p -R --no-ext-diff --no-color \
    | grep -E "^(diff|(old|new) mode)" --color=never  \
    | git apply
git構成のエイリアスとして追加することもできます...
git config --global --add alias.permission-reset '!git diff -p -R --no-ext-diff --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply'
...そして、それを呼び出すことができます:
git permission-reset
シェルがの場合はbash、必ず引用符の'代わりに使用してください。そうしないと、最後に実行したコマンドで置き換えられます。"!gitgit
@MixologicのThxは、単に-Ron を使用するだけgit diffで、面倒なsedコマンドが不要になったことを指摘しています。
fatal: unrecognized input
                    試す git config core.fileMode false
git configmanページから:
core.fileModefalseの場合、インデックスと作業コピーの間の実行可能ビットの違いは無視されます。FATなどの壊れたファイルシステムで役立ちます。git-update-index(1)を参照してください。
デフォルトはtrueですが、リポジトリの作成時にgit-clone(1)またはgit-init(1)が適切にプローブしてcore.fileModeをfalseに設定する場合を除きます。
git checkout origin/masterサーバーにコミットされたファイル権限をローカルの作業コピーに設定することは可能ですか?なぜなら、ArangoDB用にV8をビルドするたびに、ファイルのアクセス許可が変更されるため、ビルドフォルダー全体へのアクセスが拒否されるからです(昇格された権限でもWindows 7以降)。ビルドプロセスを続行する前に、すべてのローカルファイルの権限を修正する必要があります。core.filemode falseそれも修正できますか?私はgitが私のWindowsマシンにLinuxパーミッションを設定しているのではないかと疑っています。ビルドスクリプトはそれらを保持し、新しく作成されたファイルに同じ権限を適用するだけかもしれません...
                    filemodeすることにマイナス面があるかどうか疑問に思っていますfalse!
                    Gitは実行可能スクリプト以外のファイル権限を保存しません。git-cache-metaなどを使用して、ファイルの所有権と権限を保存することを検討してください。
Gitは755(実行可能)と644(実行不可)の2種類のモードしか保存できません。ファイルが444の場合、gitには644が格納されます。
umaskと、構成設定に基づいて表示されます。stackoverflow.com/ a / 12735291/125150を参照してください。
                    ...a mode of 100644, which means it’s a normal file. Other options are 100755, which means it’s an executable file; and 120000, which specifies a symbolic link. The mode is taken from normal UNIX modes but is much less flexible — these three modes are the only ones that are valid for files (blobs) in Git (although other modes are used for directories and submodules).
                    git diff -p \
| grep -E '^(diff|old mode|new mode)' \
| sed -e 's/^old/NEW/;s/^new/old/;s/^NEW/new/' \
| git apply
ほとんどの場合に機能しますが、meldなどの外部diffツールがインストールされている場合は、-no-ext-diffを追加する必要があります
git diff --no-ext-diff -p \
    | grep -E '^(diff|old mode|new mode)' \
    | sed -e 's/^old/NEW/;s/^new/old/;s/^NEW/new/' \
    | git apply
私の状況では必要でした
pre / postチェックアウトフックを試すこともできます。
git diff -pmuhquの回答で使用されている場合、すべての不一致が表示されるとは限りません。
core.filemodeているfalse(MSysGitのデフォルトです)このコードは、代わりにメタデータを直接読み取ります。
(set -o errexit pipefail nounset;
git ls-tree HEAD -z | while read -r -d $'\0' mask type blob path
do
    if [ "$type" != "blob" ]; then continue; fi;
    case "$mask" in
    #do not touch other bits
    100644) chmod a-x "$path";;
    100755) chmod a+x "$path";;
    *) echo "invalid: $mask $type $blob\t$path" >&2; false;;
    esac
done)
非生産グレードのワンライナー(マスクを完全に置き換えます):
git ls-tree HEAD | perl -ne '/^10(0\d{3}) blob \S+\t(.+)$/ && { system "chmod",$1,$2 || die }'
(「$ '\ 0'」のクレジットはhttp://transnum.blogspot.ru/2008/11/bashs-read-built-in-supports-0-as.htmlに移動します)
最も簡単な方法は、権限を元に戻すことです。@krogerが指摘したように、gitは実行可能なビットのみを追跡します。したがって、おそらくchmod -x filenameそれを修正するために実行する必要があります(または+xそれが必要な場合)。
git show:差分--git A / OpenWatch / SRC / ORG /エール/ openwatch / FB / FBUtils.java B / OpenWatch / SRC / ORG /エール/ openwatch / FB / FBUtils.javaインデックスcd6fa6a..e5b0935 100644   それ太字のビットはファイルのアクセス許可です。
                    100644ました100755。許可をからに変更できませんでした。私はあなたが反対票を投じる価値があるとは思いません。Gitは反対票です。それは非常に多くの異なるレベルで非常に多くの方法で壊れています...
                    このetckeeperツールは、アクセス許可を次のように処理できます。
etckeeper init -d /mydir
以外のディレクトリにも使用できます/etc。
パッケージマネージャーを使用してインストールするか、上記のリンクからソースを取得します。