Почему я получаю различия, от которых я не могу избавиться при переключении ветвей в git и как их исправить?

Question

Вот некоторый уместный выход из командной строки (с poshgit отображения статуса):

[Branch1]> git checkout Branch2 
Switched to branch 'Branch2' 
[Branch2 +0 ~3 -0]> 
[Branch2 +0 ~3 -0]> git diff --ignore-space-at-eol 
[Branch2 +0 ~3 -0]> git checkout . 
[Branch2 +0 ~3 -0]> 

Я попытался решение предложило в this question

[Branch2 +0 ~3 -0]> git reset --hard 
HEAD is now at c8be749 some comment 
[Branch2 +0 ~3 -0]> git reset HEAD 
Unstaged another commit: 
M  Src/somefile 
M  Src/someotherfile.cs 
M  Src/athirdfile.cs 
[Branch2 +0 ~3 -0]> 

, как это происходит и как я могу это исправить кроме совершения изменений, поскольку я, похоже, не могу отменить различия. Даже скрепление ничего не делает.

Некоторые предложения о том, как мы попали в этот беспорядок и как мы можем выйти из него, будут высоко оценены.

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

Что я могу сделать, чтобы исправить эту все более раздражающую проблему?

Answer 1

Эта проблема может быть вызвана предпочтениями окончания строки в разных операционных системах.

Если вы Unix/Mac Затем пользователь установит вам конфигурации, как показано ниже

git config --global core.autocrlf input 
git config --global core.safecrlf true 

Если вы на Windows попробуйте конфигурации, как показано ниже

git config --global core.autocrlf true 
git config --global core.safecrlf true 

После выполнения этих настроек, когда вы переключаете ветки затем git status не должен жаловаться ни на что.

Answer 2

Вы не указали, какую ОС вы используете, какую ОС использует ваш удаленный репо (если есть), или ваша команда работает кросс-платформенной с другими ОС. Такая информация может помочь диагностировать проблему.

Я видел подобные проблемы возникают из-за:.

• линия окончания (Windows против Mac против Linux)

  Вы это исправить с сердцевиной * Настройка CRLF и .gitattributes файлов , Страница справки github для этого и справочная система gitattributes - это большие ресурсы для этого.

  Trying to fix line-endings with git filter-branch, but having no luck https://help.github.com/articles/dealing-with-line-endings https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

  Не пропустите часть в конце GitHub помощь, которая говорит о том, как вы должны нормализовать ваш репозиторий после получения этой установки:

  После вы установили параметр core.autocrlf и зафиксировали файл .gitattributes, , вы можете обнаружить, что git хочет зафиксировать файлы, которые вы не изменили. Это потому, что git хочет нормализовать окончание строк для вас. Лучший способ сделать это ...

• нечувствительные к регистру файловых систем, когда файлы/каталоги с несовпадающими случае уже существуют

  В частности, что Src реж выглядит особенно подозрительным мне. Обычно это происходит потому, что кто-то переименовал файл в репо с тем же именем, но использовал другой случай для одной или нескольких букв. Затем кто-то обновляет локальное репо и рабочий каталог, git сообщает файловой системе (case-insenstive filesystem), что файл/dir уже существует, но другой git-код будет обрабатывать файл/dir как новый.

  Попробуйте сделать новый клон в новый или пустой каталог. Посмотрите, отличаются ли имена букв имени/имени файла между путями проблемных файлов в вашем новом клоне и исходном клоне (посмотрите на файл Src - это может быть src в репо. Если доступно, я бы сделал свежий клон в системе Unix/Linux.

• символов Unicode в именах файлов

  Это, кажется, не быть для вашей проблемы, но я подумал, что стоит упомянуть для полноты картины. Это вариант случая -инчувствительность, но также влияет на то, как файловая система обрабатывает символы Unicode в именах файлов.

  См. Git clean not removing a file для описания Крипция проблемы, с которой кто-то еще сталкивался с Unicode в именах файлов.

Answer 3

git clean -id должен делать то, что вы ищете.

i позволит вам проверить, что удаляется, а d сообщает об удалении дополнительных каталогов. Просто будьте осторожны, чтобы он не вычищал слишком много и вынимал все, что вы хотите сохранить.