出于某种原因,当我最初为我的git项目从存储库中提取时, 我的工作副本中有大量的文件,它们没有明显的更改,但一直出现在我的非阶段性更改区域中。
我在Windows xp上使用Git Gui,当我去看文件,看看有什么改变。 我看到的是:
old mode 100755
new mode 100644
有人知道这是什么意思吗?
如何将这些文件从未分级更改列表中删除?(为了挑出我最近编辑过并想提交的文件,不得不浏览100个文件,这很烦人)。
出于某种原因,当我最初为我的git项目从存储库中提取时, 我的工作副本中有大量的文件,它们没有明显的更改,但一直出现在我的非阶段性更改区域中。
我在Windows xp上使用Git Gui,当我去看文件,看看有什么改变。 我看到的是:
old mode 100755
new mode 100644
有人知道这是什么意思吗?
如何将这些文件从未分级更改列表中删除?(为了挑出我最近编辑过并想提交的文件,不得不浏览100个文件,这很烦人)。
当前回答
我曾经遇到过这个问题,当从旧硬盘驱动器复制工作文件的git repo几次。该问题源于所有者和权限从旧驱动器/机器更改到新驱动器/机器的事实。简而言之,运行以下命令来解决问题(感谢超级用户的回答):
sudo chmod -R -x . # remove the executable bit from all files
前一个命令将实际解决git diff报告的差异,但将撤销您列出目录的能力,因此ls ./失败,ls: .:权限被拒绝。要解决这个问题:
sudo chmod -R +X . # add the executable bit only for directories
坏消息是,如果您确实有任何想要保持可执行的文件,例如.sh脚本,则需要恢复它们。你可以为每个文件执行以下命令:
chmod +x ./build.sh # where build.sh is the file you want to make executable again
其他回答
这与bkm的发现类似,但它也会考虑任何已删除的文件,并且只在应用更改时给出警告。
这可以很好地恢复上次提交的文件模式设置。
git diff -p --no-ext-diff --no-color --diff-filter=d | grep -E "^(diff|old mode|new mode)" | sed -e "s/^old/NEW/;s/^new/old/;s/^NEW/new/" | git apply
这招对我很管用:
git ls-files -m | xargs -L 1 chmod 644
该解决方案将git文件权限从100755更改为100644,并将更改推回bitbucket远程回购。
看看你的回购的文件权限:git ls-files——stage 如果100755而你要100644
然后执行如下命令: Git ls-files——stage | sed 's/\t/ /g' | cut -d' ' -f4 | xargs Git update-index——chmod=-x
现在再次检查你的回购文件权限:git ls-files——stage 现在提交您的更改:
吉特状态
Git commit -m“恢复文件权限”
git push
我也遇到过同样的问题。这救了我的命:
这将把所有权限还原为差异,这样您就什么都没有了,只剩下您对文件所做的更改。
https://gist.github.com/jtdp/5443498
git diff -p -R --no-color \
| grep -E "^(diff|(old|new) mode)" --color=never \
| git apply
详情见https://stackoverflow.com/a/4408378/450383
设置git配置核心的可接受答案。Filemode false,工作,但有后果。设置的核心。Filemode to false告诉git忽略文件系统上的任何可执行位变化,这样它就不会将其视为更改。如果您确实需要在将来的任何时候对这个存储库进行可执行位更改,您将不得不手动执行,或者设置core。文件模式返回为true。
如果所有修改的文件都应该具有模式100755,那么另一种影响较小的替代方法是执行如下操作
chmod 100755 $(git ls-files --modified)
它只是做了模态的改变,不多不少,没有额外的含义。
(在我的例子中,这是因为在MacOS上OneDrive与我的文件系统同步;不改变核心。filemode,我保留了模式改变可能在未来再次发生的可能性;就我的情况而言,我想知道它是否会再次发生,以及改变核心。filemode将隐藏它从我,这是我不想要)