Answers:
当使用来创建补丁时,Git会跟踪文件权限并公开权限更改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
请注意,如果shell为bash
,请确保使用'
而不是"
引号!git
,否则它将被git
您运行的最后一个命令代替。
感谢@Mixologic指出,只需使用-R
on git diff
,sed
就不再需要繁琐的命令。
fatal: unrecognized input
尝试 git config core.fileMode false
从git config
手册页:
core.fileMode
如果为false,则忽略索引和工作副本之间的可执行位差异;对于像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(非可执行)。如果您的文件是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),则必须添加--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-Git挂钩
git diff -p
在muhqu的答案中使用的词语可能不会显示所有差异。
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
:DIFF --git一个/ OpenWatch / SRC /组织/ ALE / openwatch / FB / FBUtils.java B / OpenWatch / SRC /组织/ ALE / openwatch / FB / FBUtils.java索引cd6fa6a..e5b0935 100644 即粗体位表示具有文件权限。
100644
为100755
。我认为你不应该被否决。Git应该被否决。它在许多不同的层面上以多种方式被破坏了……