如果你也和我一樣，使用雙（甚至是多）系統(tǒng)。平時(shí)使用Linux來(lái)進(jìn)行工作。偶爾使用Windows進(jìn)行娛樂(lè)。那就會(huì)有文件共享的問(wèn)題。
我把數(shù)據(jù)盤格式化為NTFS格式。以方便在Linux和Window系統(tǒng)之間進(jìn)行數(shù)據(jù)共享。在使用GIT工作時(shí)，有時(shí)候就發(fā)現(xiàn)，新Clone下來(lái)的項(xiàng)目，在沒(méi)有做任何修改的前提下，git status命令提示幾乎所有文件都有修改。這就造成無(wú)法進(jìn)行后續(xù)的git pull更新操作。使用git pull -f參數(shù)也沒(méi)有。
如下圖所示：
$ git status
modified: service-loadbalancer/test-samples/TestDefaultCustomAlgorithm.cfg
modified: service-loadbalancer/test-samples/TestServiceAffinity.cfg
modified: service-loadbalancer/test-samples/TestServiceAffinityWithCookies.cfg
modified: service-loadbalancer/test-samples/TestSvcCustomAlgorithm.cfg
modified: service-loadbalancer/test-samples/TestSyslog.cfg
modified: service-loadbalancer/test-samples/loadbalancer_test.json
modified: test-utils/.gitignore
modified: test-utils/README.md
modified: test-utils/utils/utils.go
...
...
$ git diff test-utils/utils/utils.go
diff --git a/test-utils/utils/utils.go b/test-utils/utils/utils.go
old mode 100644
new mode 100755
原始文件并沒(méi)有修改，只是文件的權(quán)限被修改了。原因是NTFS沒(méi)有Linux下豐富的權(quán)限設(shè)置。clone下來(lái)的文件都被設(shè)置成了所有人員可讀寫。
$ ll test-utils/utils/utils.go
-rwxrwxrwx 1 root root 3597 Apr 7 09:23 test-utils/utils/utils.go
而且通過(guò)chmod修改權(quán)限也不會(huì)生效。
$ chmod 644 test-utils/utils/utils.go
$ ll test-utils/utils/utils.go
-rwxrwxrwx 1 root root 3597 Apr 7 09:23 test-utils/utils/utils.go
總不能把文件系統(tǒng)重新格式化了再用吧 :-(
既然是文件權(quán)限的問(wèn)題，而且文件只是權(quán)限發(fā)生了變化。那git有沒(méi)有可以忽略這種權(quán)限變化的選項(xiàng)呢？
答案當(dāng)然是YES
core.fileMode
Tells Git if the executable bit of files in the working tree is to be honored.
Some filesystems lose the executable bit when a file that is marked as executable is
checked out, or checks out an non-executable file with executable bit on. [git-clone(1)]
(https://www.kernel.org/pub/software/scm/git/docs/git-clone.html) or [git-init(1)]
(https://www.kernel.org/pub/software/scm/git/docs/git-init.html) probe the filesystem to
see if it handles the executable bit correctly and this variable is automatically set as
necessary.
A repository, however, may be on a filesystem that handles the filemode correctly, and
this variable is set to *true* when created, but later may be made accessible from
another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting
a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be
necessary to set this variable to *false*. See [git-update-index(1)]
(https://www.kernel.org/pub/software/scm/git/docs/git-update-index.html).
The default is true (when core.filemode is not specified in the config file).
通過(guò)在倉(cāng)庫(kù)中設(shè)置filemode為false。就可以解決問(wèn)題：
$ git config core.filemode false
$ git st
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
或者，如果你嫌麻煩，也可以把這個(gè)設(shè)置配置到全局配置中。
$ git config --global core.filemode false
不過(guò)要注意，設(shè)置全局的配置有一點(diǎn)點(diǎn)安全風(fēng)險(xiǎn)性。如果某個(gè)文件被錯(cuò)誤的配置了可執(zhí)行權(quán)限，或者某些文件的可讀寫權(quán)限沒(méi)有適當(dāng)?shù)呐渲谩t在Linux系統(tǒng)下程序被安裝后，可能會(huì)引起錯(cuò)誤。原代碼之類的，問(wèn)題還不大。對(duì)于腳本、二進(jìn)制程序權(quán)限還是明確配置了比較好。
