Как должен вести себя git, когда две ссылки на один и тот же файл отличаются?

Question

Я наблюдал следующее поведение при работе с базой кода perl (в ветке maint-5.004):

bash-3.2$ git status | grep modified
#       modified:   configure
bash-3.2$ git reset --hard
HEAD is now at 9a4fb7e copy over bleads .gitignore
bash-3.2$ git status | grep modified
#       modified:   Configure
bash-3.2$ git reset --hard
HEAD is now at 9a4fb7e copy over bleads .gitignore
bash-3.2$ git status | grep modified
#       modified:   configure

Это происходит потому, что два файла совместно используют индекс (это один и тот же файл), но они отличаются в индексе git.Мой вопрос заключается в следующем:как это произошло?Если git отслеживает 2 ссылки на один и тот же файл, следует ли ожидать, что git пометит это как ошибку, когда будет изменена только одна из них?Это ошибка git или пользователя?

Обновить:

Похоже, что проблема не в git, а связана с чувствительностью файловой системы к регистру (hfs +).

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

Я думаю, возможно, что OS X необходимо пересмотреть как полезную платформу для разработки, поскольку такое поведение абсурдно.

Answer 1

Системы управления версиями обычно имеют проблемы с отслеживанием жестких ссылок.Вам следовало бы сделать один из них символической ссылкой и добавить символическую ссылку в git, и это работало бы нормально.Git прекрасно справляется с символическими ссылками.

Если вы каким-то образом не укажете системе управления версиями, что файл, который вы добавляете в репозиторий, является жесткой ссылкой, у нее нет способа узнать, и она, конечно, не будет сравнивать индексы всех файлов при каждом добавлении только для того, чтобы выяснить, так ли это.

Даже системы, которые допускают жесткие ссылки, стараются избегать их создания любой ценой, поскольку количество проблем, создаваемых жесткими ссылками, довольно велико и все возникающие в результате ошибки и несоответствия очень трудно отследить.Через некоторое время и несколько переименований и перемещений одной из ссылок каждая из двух разных команд может владеть одним фрагментом жесткой ссылки в своей части дерева исходных текстов, и начинается борьба за содержимое дерева версий объекта, причем никто не слишком разбирается в том, почему без изменений, внесенных в вашу часть дерева исходных текстов, содержимое файла меняется.Лучше использовать символические ссылки.

Answer 2

Мне кажется, это ошибка git.Насколько я понимаю, вы создали жесткую ссылку из Configure в configure, и git правильно рассматривает их как отдельные объекты, но при изменении одного из них они оба должны измениться в индексе git.

Прав ли я в оценке того, что они тесно связаны?

Answer 3

Я не уверен, что git действительно отслеживает индексные индексы, вероятно, это касается только имен файлов.Взгляните, например, на этот пример выполнения:

$ 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

Обратите внимание, что если я записываю фиксацию с изменениями только в одном из файлов, git записывает изменения в файл a и предполагает b не был изменен (как я и ожидал).Что касается git, то другой файл не был изменен.Если вы позже выполните сброс git, индексы файла больше не будут такими, какими они отличаются.

Я не смог воспроизвести поведение, о котором вы сообщили (изменения в отчете о состоянии git сразу после полной перезагрузки), и мне интересно, возможно ли это вообще (если бы не ошибка).Можете ли вы привести небольшой пример, который показывает поведение, которое вы наблюдали?