Git chmodの問題:チェックアウトスクリュー実行ビット


10

UbuntuとDebianでは、後でチェックアウトしようとすると、最後にコミットされたファイルに実行ビットが設定されています。それはかなり奇妙で、私を狂わせます:

$ ls -l file
-rw-r--r-- ... file

# on branch master:
$ git commit -m 'mode is 644' file
[master 0123456] mode is 644
 1 files changed, 1 insertions(+), 1 deletions(-)
# All ok

$ git checkout dev-branch
Switched to branch 'dev-branch'
# Seemingly all ok, but file now has the exec bit set

$ git merge master
Updating 6543210..0123456
error: Your local changes to 'file' would be overwritten by merge.  Aborting.
Please, commit your changes or stash them before you can merge.
# Oops...

$ ls -l file
-rwxr-xr-x ... file

誰かがアイデアを持っていますか?いつ、なぜ実行ビットが挿入されるのですか?core.filemodeに設定されていtrueます。

どういうわけかそれが重要であれば、ブランチの切り替え中にファイルをvimで開いています。

補遺1:権限が台無しにされるチェックアウトです。私は何度でもゲームをプレイできます:

$ git br
* master
  dev-branch

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

$ chmod 644 file

$ git diff

$ git checkout dev-branch

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

$ chmod 644 file

$ git diff

$ git checkout master

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

# ...and so on ad inf.

補遺2:ちなみに、これは私がコミットするこのリポジトリ内のすべてのファイルに対して発生します。コミットが成功した後、許可のねじ込みがなければ、ブランチを切り替えることはできません。


#一見すべてOKの手順で権限を確認しましたか?
RobotHumans 2010年

ここで同意します。dev-branchで 'git-log master ... HEAD-file'を実行し、ブランチとそのファイルの間で何か変更があったかどうかを確認します。
yuriismaster

@ aking1012:はい、その時点でファイルモードはすでに変更されています。質問を更新します。
Boldewyn 2010年

@yuriismaster:、または(これは奇妙なことではありませんか?コマンドからの最後のコミットメッセージを出力するべきではありません)のgit-log組み合わせではmaster、出力はまったく表示されませんdev-branchHEADmaster
Boldewyn

2
どのファイルシステムを使用していますか?
ビットマスク、2010年

回答:


12

Gitユーザーではありませんが、Gitはファイル許可マスク全体を保管していると思います。

これは、ファイルを実行可能に設定したことを意味します。Gitはこれを取得してリポジトリに複製します。したがって、コミットする前にファイルの権限マスク自体を変更する必要があります。

Gitにそのような変更を無視させるには、

git config core.filemode false

以下からのgit-config設定(1)

   core.fileMode
       If false, the executable bit differences between the index and the
       working copy are ignored; useful on broken filesystems like FAT.
       See git-update-index(1). True by default.

1
実際、私は正しいパーミッションでファイルをコミットしようと努力しています。すべてのファイルをchmodした後で再コミットしました。私はときどきWindowsで作業しているので(ただし、このリポジトリではありません)、についてcore.fileModeは知っていますが、それを残せるようになりたいと思っていましたtrue
Boldewyn 2010年

彼らが「壊れたファイルシステム」と呼ぶものに取り組んでいるとき、それはgitのバグかもしれません。壊れたファイルシステムはなく、壊れたソフトウェアだけです。
harrymc

4
脂肪が壊れているというgit開発者に同意する必要があります
RobotHumans

3
OK、それはファイルシステムでした。ディレクトリがNFS経由でマウントされている別のマシンでそれを再現できませんでした。メインマシンでは、前述のようにCIFSです。gitメーリングリストで質問したところ、実行ビットに関してCIFSが壊れているという答えを得ました。くそー!
Boldewyn 2010年


3

コミットまたはチェックアウト中に実行されるカスタムフックがあるかどうかを確認しましたか?ファイルを改ざんするカスタムフックがいくつかある可能性があります。チェックアウトgithooksマンページを

フックは基本的に、特定のイベント(コミット、チェックアウトなど)でgitによって呼び出される小さなプログラムです。


良い試みですが、私の.git/hooksディレクトリはそのままです。
Boldewyn、2010年

1

ブランチdev-branchでgit commit -m 'mode is 644'ファイルを試しましたか

私には、メインのアクセス許可を変更してから、間違ったアクセス許可を持つdevブランチをプルダウンし、ローカルのアクセス許可を破壊しているようです。その後、再度コミットを試みます。クローン、変更、コミット、マージのいずれか。または単一のファイルをdevにコミットして個別にファイルを変更してからマージしてみてください


1
実際、元のシナリオでは、アクセス許可には触れません。すべての権限の変更は、「チェックアウト」ステップでgitによって行われます。
Boldewyn、2010年

...つまりchmod、ファイルに対して一度ingを実行しましたが、問題がすぐに発生し始めた場合、残念ながら思い出せません。そうではなかったと思います。
Boldewyn 2010年

私はあなたの問題を再現しようとしましたが、できません
RobotHumans 2010年

これは、マウントされたCIFSで作業しないためです;-)。試してみた+1を忘れてしまいました。ありがとうございます。
Boldewyn 2010

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.