3

私はperlコードベース（ブランチmaint-5.004）で作業しているときに次の動作を観察しました：

bash-3.2$gitステータス| grepが変更されました
＃変更：構成
bash-3.2 $ git reset --hard
HEADは現在9a4fb7eにあり、bleads.gitignoreをコピーします。
bash-3.2$gitステータス| grepが変更されました
＃変更：構成
bash-3.2 $ git reset --hard
HEADは現在9a4fb7eにあり、bleads.gitignoreをコピーします。
bash-3.2$gitステータス| grepが変更されました
＃変更：構成

これは、2つのファイルがiノードを共有している（同じファイルである）が、gitインデックスが異なるために発生しています。私の質問は：それはどのように起こったのですか？gitが同じファイルへの2つのリンクを追跡している場合、そのうちの1つだけが変更されたときに、gitがエラーとしてフラグを立てることを期待する必要がありますか？これはgitのバグですか、それともユーザーエラーですか？

アップデート：

問題はgitにあるのではなく、ファイルシステム（hfs +）の大文字と小文字の区別に関連しているようです。

$ mkdir tmp
$ cd tmp
$ touch foo
$ ls -i foo Foo
10301082 Foo 10301082 foo

この振る舞いはばかげているので、おそらくOSXを開発のための有用なプラットフォームとして再考する必要があると思います。

4

3 に答える 3

1

ソース管理システムには、通常、ハードリンクの追跡に問題があります。それらの1つをシンボリックリンクにしてgitにシンボリックリンクを追加する必要があります。そうすれば正常に機能します。Gitはシンボリックリンクをうまく処理できます。

リポジトリに追加するファイルがハードリンクであることをソース管理システムに何らかの形で指摘しない限り、それを知る方法はなく、追加するたびにすべてのファイルのiノードを比較してそれが場合。

ハードリンクを許可するシステムでさえ、ハードリンクによって作成される問題の数が非常に多く、結果として生じるすべてのバグや不整合を追跡するのが非常に難しいため、ハードリンクの作成を絶対に避けようとします。しばらくして、リンクの1つの名前を変更したり移動したりすると、2つの異なるチームがそれぞれソースツリーの一部にハードリンクを1つ所有することができ、オブジェクトのバージョンツリーのコンテンツをめぐる争いが起こります。ソースツリーの一部に変更を加えずにファイルの内容を変更する理由について。シンボリックリンクを使用することをお勧めします。

于 2009-12-29T20:31:08.080 に答える
0

私にはgitバグのようです。私が理解しているように、構成から構成へのハードリンクを作成し、gitはそれらを別々のエンティティとして適切に認識していますが、一方が変更されると、両方ともgitインデックスで変更されるはずです。

これらはハードリンクされているという評価で正しいですか？

于 2009-12-29T16:15:04.947 に答える
0

gitが実際にiノードを追跡するかどうかはわかりません。おそらくファイル名にのみ関係します。たとえば、このサンプル実行を見てください。

$ mkdir so.question
$ cd so.question/
$ git init
Initialized empty Git repository in /tmp/so.question/.git/
$ echo "test" > a
$ ln a b
$ ls -i
539367 a  539367 b
$ git add a b
$ git commit -m"One"
[master (root-commit) 897cdea] One
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 a
 create mode 100644 b
$ echo "test" >> a
$ git add a
$ git commit -m"Two"
[master bbcba39] Two
 1 files changed, 1 insertions(+), 0 deletions(-)
$ ls -i
539367 a  539367 b
$ git reset --hard
HEAD is now at bbcba39 Two
$ ls -i
539367 a  539389 b

1つのファイルのみに変更を加えたコミットを記録すると、gitはファイルへの変更を記録し、変更されていないaと想定することに注意してくださいb（予想どおり）。gitに関する限り、他のファイルは変更されていません。後でgitresetを実行すると、ファイルのiノードは異なるため同じではなくなります。

私はあなたが報告した振る舞い（ハードリセット直後の変​​更を報告するgitステータス）を再現することができませんでした、そしてこれが可能であるかどうか（バグがなければ）疑問に思います。あなたが観察した行動を示す小さな例を思い付くことができますか？

于 2009-12-29T18:16:09.150 に答える