Git не вернет или не зафиксирует файл, который, по его мнению, изменен

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

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

ОС: Windows 8 Командная строка: MinGW Git версия: 1.8.1.msysgit.1

Процесс извлечения подрепозитория не работает, если у вас нет чистой промежуточной области и никаких измененных файлов.

git status сообщает мне, что у меня есть модифицированный файл, хотя это новый импорт SVN. Хорошо, пусть просто попытается избавиться от него.

Попробуйте и верните файл.

user$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")

user$ git checkout -- "folder with space/folder/toolbar.png"

user$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")

Это не сработало, но мне все равно, если я это сделаю, поэтому я попробую следующее.

user$ git commit -a -m "Testing if committing fixes it"
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")

user$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")

Завершение пропущенного этапа не работает, поэтому сначала попробуйте и выполните его.

user$ git add "folder with space/folder/toolbar.png"

user$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified: folder with space/folder/toolbar.png
#
no changes added to commit (use "git add" and/or "git commit -a")

Не работает, поэтому я в тупике... Идите и спросите кого-нибудь умнее.

Я новичок в Git, но знаком с Hg и читаю этот онлайн-учебник, чтобы начать работу.

Вполне возможно, что я испортил простую команду.

Уже пробовали: Я оглянулся вокруг решения моей конкретной проблемы, но мало повезло. Я наткнулся на этот ответ, который кажется связанным, но не совсем исправляет мою проблему.

Изменить: все, что может быть интересно Это то, что меня смущает. Я перетащил это репо некоторое время назад в онлайн-репозиторий. После нового клона репо все еще думает, что файл изменен (т.е. git status возвращает тот же результат, и я уже установил git config --global core.autocrlf false и подтвердил, выполнив git config --global core.autocrlf, который действительно возвращает false).

Изменить 2: Исправить, но проблема все еще не понята Мне удалось исправить репозиторий, просто удалив файл из системы, промежуточную область и затем совершив изменения. После этого, чтобы вернуть файл, я просто скопировал его и передал его в репозиторий.

Проблема, хотя и фиксированная, только смутила меня.

Пока я играл с удалением файла, я заметил, что если я reset репозиторий для HEAD, чья последняя фиксация удалила файл, статус Git указывает, что ничего не изменилось и что файл не но файл будет восстановлен в моем рабочем дереве. Это странно, учитывая, что он помечен как удаленный в git...

Только после удаления его во второй раз, даже если Git больше не запоминает его, удался ли я удалить его так, чтобы git reset и git reset --hard не восстанавливали файл.

Если кто-нибудь может объяснить, как я попал в это состояние, и если это ошибка в Git или нормальное поведение, я бы очень признателен.

Мои подозрения Я потерял последовательность команд, которые я использовал, но что произошло, произошло примерно так: Файл Images/toolbar.png, и я перешел в папку Images.

После того, как я удалил его из файловой системы Git, обнаружил изменение следующим образом:

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted: toolbar.png
#       deleted: ../images/toolbar.png
#

Обратите внимание, что папка Images не заглавная. Это выполняется в Windows, который игнорирует случай пути. Я подозреваю, что это может быть частью проблемы...

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

Ответы

Ответ 1

У меня была подобная проблема некоторое время назад.

Была ли сделана капитализация в этом файле или в каталоге, в котором он находился, в любой точке?

У меня был каталог с заглавной буквой, который был изменен на все строчные буквы (скажем, от t /Foo до /Foo). Это дало мне все те же проблемы, которые вы описали.

Всякий раз, когда я менял файл, он дал мне аналогичный вывод:

#       modified: bar.txt
#       modified: ../Foo/bar.txt

У меня также была та же проблема, когда фиксация или сброс не дали никаких результатов.

Я думаю, что причина проблемы заключается в том, что пути к файлам Windows не чувствительны к регистру, а относятся к Unix. Поскольку многие из этих инструментов командной строки, таких как Git, разрабатываются в Unix-y-системах, они иногда не очень хорошо справляются с этой разницей и могут запутаться, когда файл добавлен как Foo/bar.txt и Foo/bar.txt. Я думаю, что это делает Git думаю, что есть два разных файла, где на самом деле только один.

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

В любом случае, я знаю, что это не окончательный ответ, но с тех пор я смог воссоздать проблему, поэтому я уверен, что это вызвало (по крайней мере, для меня).

Ответ 2

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

Сообщение, которое я продолжал получать:

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   images/contact_seller.GIF
#

Это произошло потому, что первоначальная фиксация repo была сделана из MacBook, которая отформатирована с учетом регистра, и ошибка появилась на моем iMac, который был отформатирован без учета регистра.

На чувствительной к регистру машине вы можете увидеть два файла

SwedishChef$ ls images/contact_seller*
images/contact_seller.GIF   images/contact_seller.gif

Что недействительно на втором компьютере, поэтому git должен был что-то сделать.

Мне просто пришлось переименовать файл и зафиксировать эти изменения.