Изменение веток в git ошибочно приводит к изменению файлов

Я использую git (1.8.3) в Windows. Если я клонирую репозиторий из github, а затем немедленно проверяю другую существующую ветку в этом репо, git обнаруживает измененные файлы. Обычно. Иногда это не так. И разница во всех измененных файлах возвращается одинаковой (включая окончания строк). Эта проблема наблюдалась в 2 разных репозиториях как минимум на 4 разных компьютерах в моей команде.

И это не всегда одни и те же файлы, но почти всегда это одно из нескольких подмножеств файлов в репозитории. Например, иногда одни и те же 5 файлов в корне репозитория, иногда те же 93 файла в одной конкретной папке, иногда те же 16 файлов в другой папке.

Как только git помечает файлы как измененные, если я возвращаю их или прячу, они сразу же снова помечаются как измененные, что делает невозможным переключение между ветвями.

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

У всех нас есть core.autocrlf=true, так как мы все на Windows. Вот наши .gitattributes

# Auto detect text files and perform LF normalization
* text=auto

# Custom for Visual Studio
*.cs      diff=csharp
*.sln     merge=union
*.csproj  merge=union
*.sqlproj merge=union
*.html    text diff=html
*.css     text
*.js      text
*.ejs     text
*.sql     text

# Standard to msysgit
*.doc     diff=astextplain
*.DOC     diff=astextplain
*.docx    diff=astextplain
*.DOCX    diff=astextplain
*.pdf     diff=astextplain
*.PDF     diff=astextplain

git github windows line-endings gitattributes
person kenwarner    schedule 03.09.2013    source источник
comment
можно ли привести воспроизводимый пример проблемы?   -  person Levi Haskell    schedule 10.09.2013

Ответы (2)


arrow_upward
4
arrow_downward

Есть две ситуации, когда я видел такие вещи:

  • Окончания строк и все сумасшедшие возможности Git, чтобы справиться с ними на разных платформах. (Я вообще не использую эти функции сам, и я предпочитаю хранить и работать с файлами с одинаковыми окончаниями строк LF, в том числе в Windows.)

  • Репозитории, в которых есть два или более файлов, имена которых различаются только регистром. Например, readme.txt и ReadMe.txt. Git для Windows с трудом справляется с такими ситуациями, потому что есть только один базовый файл, к которому можно получить доступ под двумя разными именами.

person Greg Hewgill    schedule 04.09.2013
comment
Что касается чувствительности к регистру: возможно, git ls-files поможет вам увидеть, что у git есть в магазине (хотя у меня нет машины с Windows, чтобы проверить это...) - person LeGEC; 11.09.2013

arrow_upward
2
arrow_downward

Никогда не устанавливайте core.autocrlf на true, всегда на false.

Это так просто: это глобальная установка с непредвиденными последствиями.

Если у вас есть определенные типы документов, которыми вы хотите управлять с точки зрения eol, делайте это только через .gitattributes файлы и core.eol директивы.

Это означает: сначала избавьтесь от автоматического изменения каталога eol (например, вашего * text=auto), отправьте эту модификацию обратно в вышестоящий репо и посмотрите, сохраняется ли проблема.

Затем и только тогда повторно введите эти директивы, но не для всех файлов (не для '*'), а только для файлов, которые вы абсолютно хотите нормализовать eol.
И проверьте, работает ли это.

person VonC    schedule 09.09.2013