Как в Git зафиксировать изменения имен файлов с учетом регистра только с учетом регистра?

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


person Gil Shulman    schedule 16.07.2013    source источник
comment
@n, если это не совсем правильно, Git на самом деле имеет параметр конфигурации, который контролирует, игнорирует ли он чувствительность к регистру.   -  person    schedule 17.07.2013
comment
См. stackoverflow.com/a/24979063/6309: начиная с git 2.0.1, работает простой git mv.   -  person VonC    schedule 27.03.2015
comment
возможный дубликат Git: изменение заглавных букв в именах файлов   -  person KyleMit    schedule 20.08.2015
comment
@nif Просто хотел добавить (несколько лет спустя;), что HFS можно сделать чувствительным к регистру, но по умолчанию он не чувствителен к регистру. У меня есть отдельный раздел размером 65 ГиБ, отформатированный с учетом регистра HFS, который я использую для своих git рабочих копий. Я должен признать, что избавляет меня от рассудка ...   -  person Per Lundberg    schedule 09.02.2017


Ответы (16)


Если вы просто переименовываете файл, а не папку, вы можете просто использовать git mv:

git mv -f yOuRfIlEnAmE yourfilename

(Начиная с изменения в Git 2.0.1, флаг -f в приведенном выше заклинании лишнее, но это было необходимо в старых версиях Git.)

person Keith Smiley    schedule 03.01.2014
comment
это дает мне "исходный каталог пуст", пока он не - person WiseStrawberry; 19.07.2014
comment
Попробовал и получил fatal: renaming '...' failed: File exists. Я делаю это на виртуальной машине Ubuntu, которая работает в OSX - person HEKTO; 28.09.2016
comment
Здесь используется MacOS (FS без учета регистра) и -f работают! Спасибо за совет - person caesarsol; 15.12.2016
comment
@WiseStrawberry, если в пути к файлу есть пробелы, попробуйте заключить его в кавычки. - person StoriKnow; 22.03.2017
comment
Не забудьте указать полный путь к файлу. Очевидно, я знаю, но на какое-то время - person rickrizzo; 15.08.2017
comment
Как указал WiseStrawberry, это может привести к ошибке «Исходный каталог пуст» при применении к папкам в корневом каталоге git. (вложенные папки, похоже, работают нормально) - person Stevoisiak; 29.08.2017
comment
Это не работает для меня в каталоге, который я хочу переименовать (failed: Invalid argument) с полным путем к файлу и без него. странный. - person Damon; 24.02.2018
comment
Вы не можете перемещать каталоги с помощью git mv. Вам нужно будет сделать каждый файл в каталоге, если вы пытаетесь изменить регистр имени каталога. - person Sam Soffes; 15.09.2018
comment
Как ни странно, чтобы это работало в Mac OS, мне сначала пришлось переименовать данный файл TestCase.ts в TestcaseSomething.ts, зафиксировать его, а затем исправить до желаемого результата Testcase.ts перед окончательным зафиксировать и нажать. - person Patrick; 21.11.2018
comment
Наверх прокомментировал: вам действительно нужен переключатель -f с последней версией git (2.18), иначе вы можете получить fatal: destination exists ошибку. - person DeepSpace101; 15.02.2019
comment
git mv -f {O, o} ldFileNameCase - person Brian Peterson; 09.01.2020
comment
Если я сделаю это, я увижу, что файл был удален из Git, но он не отслеживает новый файл. - person Amy Pellegrini; 16.04.2020
comment
Отлично работал на Mac OS Catalina с git 2.24.0 - person Liran H; 16.06.2020
comment
Важно отметить, что это не сработает, если вы пытаетесь переименовать каталог вместо файла. Если вам нужно переименовать каталог, вы должны вместо этого сделать git mv для каждого файла в каталоге. - person Chris Charabaruk; 18.11.2020

В Git есть параметр конфигурации, который сообщает ему, следует ли ожидать файловую систему с учетом регистра или нечувствительность к регистру: core.ignorecase. Чтобы Git учитывал регистр, просто установите для этого параметра значение false. (Будьте осторожны, если вы уже отправили файлы, вы должны сначала переместить их, учитывая другие ответы).

git config core.ignorecase false

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

Документация

Из git config документации:

core.ignorecase

Если true, этот параметр включает различные обходные пути, позволяющие git лучше работать с файловыми системами, которые не чувствительны к регистру, например FAT. Например, если список каталогов находит makefile, когда git ожидает Makefile, git предположит, что это действительно тот же файл, и продолжит запоминать его как Makefile.

По умолчанию установлено значение false, за исключением git-clone (1) или git-init (1) проверит и установит core.ignorecase true при создании репозитория.

Файловые системы без учета регистра

Две самые популярные операционные системы с файловыми системами без учета регистра, о которых я знаю:

  • Окна
  • OS X
person Community    schedule 16.07.2013
comment
Это хороший ответ, и он сработал для меня, но будьте осторожны при этом, потому что это меняет вашу производственную среду. Поэтому внимательно обдумайте это изменение, прежде чем вносить его. - person usumoio; 09.01.2014
comment
Оказывается, это было включено по умолчанию в проекте. Несомненно, сделало жизнь немного интереснее. - person Matthew Setter; 26.03.2014
comment
Похоже, вам нужно сделать это для каждого репозитория git, который у вас есть. Как установить глобальный? - person Mateus Viccari; 13.12.2014
comment
Кстати, я не думаю, что Mac OS X нечувствительна к регистру. Вместо этого чувствительность к регистру определяет файловая система. При форматировании раздела HFS + пользователи могут выбирать, делать ли его чувствительным к регистру или нечувствительным. По умолчанию регистр не учитывается. - person spaaarky21; 16.12.2014
comment
В этом ответе, по-видимому, стоит отметить, что установка для этого параметра значения false в файловой системе без учета регистра является плохой идеей. Это не обязательно очевидно. Например, я просто попробовал это на своем Mac, думая, что это решит мои проблемы, а затем переименовал файл с productPageCtrl.js в ProductPageCtrl.js. git status увидел новый файл с именем ProductPageCtrl.js, но не подумал, что productPageCtrl.js был удален. Когда я добавил новые файлы, зафиксировал их и отправил в GitHub, репозиторий GitHub теперь содержал оба файла, хотя в моем (предположительно обновленном) локальном репозитории был только один. - person Mark Amery; 09.02.2015
comment
@MarkAmery Это очень похоже на ошибку в вашем клиенте Git. Вы подали отчет? - person Domi; 13.02.2015
comment
Это отлично сработало в моей ситуации. Я переименовал три класса в Visual Studio и знал, что изменение имени произошло в файловой системе, но не заметил, что это изменение не произошло в git, пока я не создал запрос на перенос, а файлы все еще имели та же проблема с пропавшим случаем, что и раньше. - person dmoore1181; 19.01.2016
comment
@Domi, это не ошибка, это ожидаемое поведение. На самом деле, устанавливать значение false в нечувствительной файловой системе - плохая идея, потому что именно это и происходит. Причина, по которой git не видел, что файл в нижнем регистре был удален, заключается в том, что файловая система не сообщает о нем как об удаленном, поскольку она игнорирует регистр, в то время как git не делает этого, если для этого параметра установлено значение false. Дело не в том, что в именах файлов нет нижнего и верхнего регистра в ntfs или толстого, просто поиск имени файла игнорирует регистр. - person ohcibi; 02.06.2016
comment
@ohcibi С точки зрения пользователя, это все еще похоже на незрелость, поскольку можно надеяться, что ваш клиент Git достаточно умен, чтобы позаботиться об этом. Но опять же, Linux не известен тем, что пытается сделать вещи удобными, но надежными :) - person Domi; 03.06.2016
comment
@Domi git достаточно умен. Вот почему вам не следует не устанавливать для этого параметра значение false в файловой системе без учета регистра. Используйте git mv, чтобы переместить файл и посмотреть, как git управляет им. Если вы переместите файл без git, git ничего не сможет сделать, поскольку файловая система не сообщает git правду. Это проблема ntfs / fat / hfs и т.п., а не git / linux. - person ohcibi; 03.06.2016
comment
Это работает с локальным репозиторием git, но, похоже, не действует после нажатия - person Mathijs Segers; 19.10.2016
comment
@Mark Amery Меня порадовало, что git config core.ignorecase false бесполезен на Mac. Мне нужно обернуть git push / pull / checkout / status другим инструментом, чтобы обойти эту ошибку git. - person bronze man; 11.11.2016
comment
@ohcibi мне кажется, что это ошибка, если она ведет себя таким образом. Достаточно просто передать флаг FILE_FLAG_POSIX_SEMANTICS методу, чтобы проверить, существует ли файл, используя его имя с учетом регистра. Файл НЕ будет найден, если установлен этот флаг. Также для поиска файла вы можете использовать FileFirstFileEx с FIND_FIRST_EX_CASE_SENSITIVE. Ссылки: mathematica.stackexchange.com/questions/97734 / msdn. microsoft.com/en-us/library/windows/desktop/ - person Jeremy; 28.09.2017
comment
Отлично работал у меня в Windows 10, клиент GitKraken. - person John Hatton; 19.09.2018
comment
Сообщение должно быть отредактировано, чтобы включить в него различные предупреждения, упомянутые здесь. Я потратил на это много времени. - person bluephoton; 01.02.2019
comment
Использование fs / os без учета регистра для работы с именами файлов, чувствительных к регистру, является ошибкой в ​​вашем рабочем процессе. - person Dávid Horváth; 30.06.2019
comment
Запуск $>git config core.ignorecase даст вам текущую настройку. В моем случае это было true. Следовательно, изменения регистра расширения имени файла не были идентифицированы. Запуск $> git config core.ignorecase false сделал свое дело и сработал как шарм. Обратите внимание, что мне пришлось перезапустить Visual Studio 2017. - person Dinesh Halpage; 23.01.2020
comment
OP означает macOS или OSX? - person mesqueeb; 28.08.2020
comment
Комментарий @ MarkAmery от 2015 года. То, что он описывает (сохранение старого файла), больше не происходит. - person Loolooii; 08.10.2020
comment
@Loolooii это все еще происходит с git 2.29.2 - person Nikolai; 24.11.2020
comment
Добавьте глобальный флаг через: git config --global core.ignorecase false - person Abel Wenning; 04.02.2021
comment
Работал на MacO, однако следует отметить, что это создавало повторяющиеся файлы. - person Daniel Lefebvre; 22.04.2021
comment
@MarkAmery: Ваш комментарий является ценным предупреждением, я взял на себя смелость добавить его к ответу. - person sleske; 12.05.2021
comment
@sleske Хм. Я не буду удалять это предупреждение, но после дальнейшего размышления, поскольку я оставил этот комментарий, я думаю, что настоящая проблема в том, что этот ответ в корне неверен. Этот вопрос касается файловых систем без учета регистра (поскольку в файловых системах с учетом регистра вы можете обрабатывать изменение регистра, как и любое другое переименование), и поскольку установка ignorecase на false в файловой системе без учета регистра нарушает работу и не помогает при все, мне кажется, что этот ответ просто бесполезен ни при каких обстоятельствах. [1/2] - person Mark Amery; 12.05.2021
comment
[2/2] Таким образом, мне кажется, что отредактированное предупреждение торпедирует весь ответ - кстати, это равносильно предупреждению о том, что этот ответ неверен, и вы должны его игнорировать. У меня смешанные чувства по поводу таких предупреждений. На самом деле, я думаю, что этот ответ должен получить сильное отрицательное голосование, но, к сожалению, только небольшая часть из более чем 250 проголосовавших за мой комментарий, указывающих на проблемы с ответом, проголосовала против ответа. Я не уверен, что лучше всего продолжить. ¯ \ _ (ツ) _ / ¯ - person Mark Amery; 12.05.2021
comment
@MarkAmery: Да, проблема довольно сложная, и, похоже, есть проблемы со всеми возможными решениями - FS без учета регистра просто отстой: - /. Может быть, позже я придумаю лучшую редакцию. - person sleske; 12.05.2021

Используя SourceTree, я смог сделать все это из пользовательского интерфейса.

  1. Переименовать FILE.ext в whatever.ext
  2. Подготовить этот файл
  3. Теперь переименуйте whatever.ext в file.ext
  4. Снова обработайте этот файл

Это немного утомительно, но если вам нужно сделать это только с несколькими файлами, это довольно быстро

person CBarr    schedule 28.10.2016
comment
То же самое с git bash - person Alex78191; 03.06.2017
comment
Сделайте этот файл важной частью - ни один из других ответов выше не сработал для меня. На самом деле он работал с простой старой командной строкой Windows. - person Vlad Sabev; 21.12.2017
comment
Я не понимал, что это сработало на этапе подготовки. Но в моем случае я хотел изменить имена папок, а также некоторые файлы в этих папках. Поэтому я сначала переименовал все папки во временные имена. Зафиксировал новые имена (все файлы внутри) и удаленные файлы. Git пометил их все как переименованные. Затем переименовал все эти папки обратно в их новые версии дел и снова зафиксировал. Наконец, объединили эти 2 коммита. Но исходя из того, что вы написали, я мог бы сделать все это напрямую через область насыщения, не создавая 2 коммита + слияние. - person ThermoX; 12.10.2018
comment
Также работает с gitkraken по имени папки. - person Philippe Matray; 29.10.2018
comment
Если ваша операционная система нечувствительна к регистру, изменения имени файла не будут отображаться в Sourcetree. - person png; 11.03.2020

Вот что я сделал в OS X:

git mv File file.tmp
git mv file.tmp file

Два шага, иначе я получу ошибку «файл существует». Возможно, это можно сделать за один шаг, добавив --cached или что-то подобное.

person Sijmen Mulder    schedule 13.11.2013
comment
как следует из верхнего ответа, -f (сила) - это флаг, который вы ищете - person rperryng; 10.07.2015
comment
@rperryng - нет, флаг -f не помогает, если базовая FS не чувствительна к регистру. Однако у меня сработало двухэтапное решение. - person HEKTO; 28.09.2016
comment
Использование FS без учета регистра (на Mac) и -f работало! Спасибо за совет - person caesarsol; 15.12.2016
comment
Это также работало с папкой в ​​Windows без флага -f. - person nich; 03.10.2017
comment
git -c "core.ignorecase=false" add . будет рассматривать файлы, регистр которых был изменен для фиксации. - person nietonfir; 12.11.2017

Иногда полезно временно изменить чувствительность к регистру в Git.

Метод № 1. Изменение чувствительности к регистру для одной команды:

git -c core.ignorecase=true checkout mybranch, чтобы отключить чувствительность к регистру для одной checkout команды. Или в более общем плане: git -c core.ignorecase= <<true or false>> <<command>>. (Благодарим VonC за предложение этого в комментариях.)

Метод № 2. Изменение чувствительности к регистру для нескольких команд:

Чтобы изменить настройку на более длительный срок (например, если необходимо выполнить несколько команд, прежде чем вернуть ее обратно):

  1. git config core.ignorecase (возвращает текущую настройку, например, false).
  2. git config core.ignorecase <<true or false>> - установите желаемый новый параметр.
  3. ... Выполнить несколько других команд ...
  4. git config core.ignorecase <<false or true>> - вернуть значение конфигурации к предыдущему значению.
person Steve Chambers    schedule 10.07.2018
comment
Почему не прямо git -c core.ignorecase=<true or false> checkout <<branch>>? Ничего не сбрасывать после. - person VonC; 10.07.2018
comment
У меня был странный опыт работы предлагаемого core.ignorecase при переходе с нижнего регистра на верхний, но не с верхнего на нижний. кажется, единственное надежное решение - прекратить использование ОС, которая не распознает регистр имен файлов. - person CodingMatters; 30.09.2018
comment
Есть ли причина, по которой это должно быть временное изменение? Вызовет ли это какие-либо проблемы, если я просто оставлю настройки с учетом регистра? - person cytsunny; 24.01.2019
comment
Это может зависеть от нескольких факторов, в частности от того, является ли целевая файловая система чувствительной к регистру - см. ru. wikipedia.org/wiki/Case_sensitivity#In_filesystems. Временное изменение может потребоваться, если файловая система развертывания имеет различную чувствительность к регистру файловой системы, используемой для разработки. Также в моем случае я работаю в команде, где ожидается, что у всех будут одинаковые настройки Git (т.е. с учетом регистра), поэтому, если я отключу его, это должно быть временным. - person Steve Chambers; 24.01.2019

Я использовал следующие шаги:

git rm -r --cached .
git add --all .
git commit -a -m "Versioning untracked files"
git push origin master

Для меня это простое решение

person andrewvergel    schedule 05.04.2019
comment
Это решение. И в отличие от других ответов он хорошо работает, когда вы выполняете пакетное переименование. На сайте glamourphilly.org нам нужно было изменить каждый .Jpg на .jpg. В Finder вы можете выполнять такие групповые переименования, и этот ответ позволяет вам проверить это. - person William Entriken; 10.12.2019
comment
Для меня это тоже было единственное простое решение - person Bálint Juhász; 01.10.2020
comment
Это сработало безупречно, спасибо. - person Kodie Grantham; 05.03.2021

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

Запустите дисковую утилиту, создайте новый образ диска и используйте следующие настройки (или измените их по своему усмотрению, но с учетом регистра):

Снимок экрана Mac Disk Utility

Обязательно сообщите git, что теперь он находится в чувствительной к регистру FS:

git config core.ignorecase false
person user1821510    schedule 03.10.2014
comment
Нет, ядерный запускает загрузочный диск с учетом регистра на OSX. Вам придется жить без плохо написанных (кхм, Adobe) приложений или запускать их на собственной глупой виртуальной машине, но это того стоит, если вы кодируете в первую очередь для систем * nix. - person Mike Marcacci; 06.08.2015
comment
Это единственный вариант, который правильно работает. Я пробовал остальное, и вы так или иначе закончили с рассолом. Решите проблему, сделав это. - person John Hunt; 03.06.2016
comment
Обратите внимание, что в Дисковой утилите есть ошибка OS X 10.11 - она ​​не создает изображения с учетом регистра. Вам нужно использовать инструмент командной строки hdiutil. apple.stackexchange.com/questions/217915/ - person dellsala; 18.01.2017
comment
С APFS в High Sierra это еще проще. Щелкните значок диска со знаком плюса и добавьте том с учетом регистра без ограничений по размеру. Он просто разделяет пространство с основным томом и монтируется в / Volumes / имя-тома. - person Michael Fox; 30.08.2017

Мы можем использовать команду git mv. Пример ниже, если мы переименовали файл abcDEF.js в abcdef.js, мы можем запустить следующую команду из терминала

git mv -f .\abcDEF.js  .\abcdef.js
person Community    schedule 26.03.2020
comment
Форсирование больше не требуется с git v2.0.1 (@see github.com/git/git/commit /) - person Julian Hofmann; 18.06.2020

Подобно ответу @Sijmen, это то, что сработало для меня в OSX при переименовании каталога (вдохновлено этим ответ из другого сообщения):

git mv CSS CSS2
git mv CSS2 css

Простое выполнение git mv CSS css дало ошибку неверного аргумента: fatal: renaming '/static/CSS' failed: Invalid argument возможно, потому что файловая система OSX без учета регистра

p.s Кстати, если вы используете Django, collectstatic также не распознает разницу в регистре, и вам также придется делать это вручную в статическом корневом каталоге

person Anupam    schedule 22.05.2019

  1. переименовать файл Name.jpg в name1.jpg

  2. зафиксировать удаленный файл Name.jpg

  3. переименовать файл name1.jpg в name.jpg

  4. изменить добавленный файл name.jpg на предыдущую фиксацию

    git add name.jpg
    git commit --amend
    
person razon    schedule 03.10.2016
comment
Я получаю это fatal: bad source, source=name1.jpg, destination=name.jpg на шаге 3. Есть ли у вас предложения? Спасибо - person Anthony Kong; 30.03.2017
comment
Вы не можете сделать коммит, просто git add. - person Alex78191; 03.06.2017
comment
Выглядит очень хакерски, не правда ли? Или исправление обезьян. - person jeromej; 02.10.2018
comment
Работал у меня. Честно говоря, это действительно правильно с точки зрения аудита. - person BeaverProj; 14.01.2021
comment
Как отмечается в ответе CBarr, вам здесь не нужна промежуточная фиксация. Вы можете просто переименовать, подготовить, переименовать, подготовить, а затем зафиксировать, без дополнительной фиксации в середине, которую использует этот ответ. - person Mark Amery; 03.05.2021

Я попробовал следующие решения из других ответов, и они не сработали:

Если ваш репозиторий размещен удаленно (GitHub, GitLab, BitBucket), вы можете переименовать файл в источнике (GitHub.com) и принудительно переименовать файл сверху вниз.

Приведенные ниже инструкции относятся к GitHub, однако общая идея, лежащая в основе них, должна применяться к любой платформе удаленного хостинга репозитория. Имейте в виду, имеет значение тип файла, который вы пытаетесь переименовать, то есть тип файла, который GitHub считает редактируемым (код, текст и т. Д.) Или нередактируемым (изображение, двоичный и т. Д.) В браузере.

  1. Посетите GitHub.com
  2. Перейдите в свой репозиторий на GitHub.com и выберите ветку, в которой вы работаете.
  3. Используя инструмент навигации по файлам на сайте, перейдите к файлу, который вы собираетесь переименовать.
  4. Does GitHub allow you to edit the file within the browser?
    • a.) Editable
      1. Click the "Edit this file" icon (it looks like a pencil)
      2. Измените имя файла в текстовом вводе имени файла
    • b.) Uneditable
      1. Open the "Download" button in a new tab and save the file to your computer
      2. Переименуйте загруженный файл
      3. На предыдущей вкладке на GitHub.com щелкните значок «Удалить этот файл» (он выглядит как мусорная корзина)
      4. Убедитесь, что установлен переключатель «Зафиксировать непосредственно в ветке branchname», и нажмите кнопку «Зафиксировать изменения».
      5. В том же каталоге на GitHub.com нажмите кнопку «Загрузить файлы».
      6. Загрузите переименованный файл со своего компьютера
  5. Убедитесь, что установлен переключатель «Зафиксировать непосредственно в ветке branchname», и нажмите кнопку «Зафиксировать изменения».
  6. Локально оформить / получить / вытащить ветку
  7. Выполнено
person gmeben    schedule 31.10.2017
comment
Я переименовал прямо на BitBucket, и это сработало. Спасибо. - person rsc; 24.12.2017
comment
Хорошо знать. Этот метод теоретически должен работать на любой платформе хостинга репозиториев, но мне было бы интересно узнать, есть ли такие, с которыми он не будет работать. - person gmeben; 02.01.2018
comment
Не работает для файлов, которые нельзя редактировать в браузере, например изображений или PDF; очевидно, что нет возможности редактирования. - person Abhijit Sarkar; 26.12.2018
comment
@AbhijitSarkar Хорошее замечание. Я обновил свой ответ для этих случаев. Я протестировал и проверил работу этой инструкции. - person gmeben; 11.01.2019

Mac OSX High Sierra 10.13 несколько исправляет это. Просто создайте виртуальный раздел APFS для своих проектов git, по умолчанию он не имеет ограничений по размеру и не занимает места.

  1. В Дисковой утилите нажмите кнопку +, когда выбран диск-контейнер.
  2. Выберите APFS (с учетом регистра) под форматом
  3. Назовите это Sensitive
  4. Выгода
  5. Необязательно: создайте в Sensitive папку с именем git и ln -s /Volumes/Sensitive/git /Users/johndoe/git.

Ваш диск будет через /Volumes/Sensitive/

введите описание изображения здесь

Как сделать фиксацию только с учетом регистра изменение имени файла в Git?

person Ray Foss    schedule 06.03.2018
comment
Мне нравится это предложение, оно элегантно и безболезненно решает проблему, не прибегая к некрасивым обходным путям. Спасибо! - person Phil Gleghorn; 25.09.2018

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

  1. удалите все файлы и папки, отличные от git, в другую папку / репозиторий.
  2. зафиксировать текущую пустую папку git (это будет отображаться, когда все файлы удалены.)
  3. добавьте все файлы обратно в исходную папку / репозиторий git.
  4. зафиксировать текущую непустую папку git.

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

person Ricardo Virtudazo Jr    schedule 29.04.2017
comment
Почему не git commmit --amend в пункте 4? В противном случае произойдет дополнительная фиксация с удалением всех файлов. Или вы можете использовать git rebase -i с сквошем. - person Alex78191; 03.06.2017

Я несколько раз сталкивался с этой проблемой на MacOS. Git чувствителен к регистру, но Mac сохраняет только регистр.

Кто-то фиксирует файл: Foobar.java и через несколько дней решает переименовать его в FooBar.java. Когда вы вытаскиваете последний код, он терпит неудачу с The following untracked working tree files would be overwritten by checkout...

Единственный надежный способ, который я видел, это исправить:

  1. git rm Foobar.java
  2. Зафиксируйте его с сообщением, которое нельзя пропустить git commit -m 'TEMP COMMIT!!'
  3. Тянуть
  4. This will pop up a conflict forcing you to merge the conflict - because your change deleted it, but the other change renamed (hence the problem) it
    1. Accept your change which is the 'deletion'
    2. git rebase --continue
  5. Теперь оставьте свой обходной путь git rebase -i HEAD~2 и drop TEMP COMMIT!!
  6. Подтвердите, что файл теперь называется FooBar.java
person Ashwin Jayaprakash    schedule 05.08.2016
comment
-1. Я не могу воспроизвести ошибку, о которой вы здесь говорите, и без нее остальная часть ответа не имеет смысла. Кроме того, выполнение git rebase --continue без выполняющейся перебазировки просто приводит к ошибке Нет перебазирования?, а на шаге 4.2 перебазирование не выполняется, поэтому выполнение этой команды также не имеет смысла. - person Mark Amery; 03.05.2021

Если ничего не помогло, используйте команду git rm filename, чтобы удалить файл с диска и добавить его обратно.

person gopal Pandey    schedule 12.04.2019

Я взял ответ @CBarr и написал скрипт Python 3 для этого со списком файлов:

#!/usr/bin/env python3
# -*- coding: UTF-8 -*-

import os
import shlex
import subprocess

def run_command(absolute_path, command_name):
    print( "Running", command_name, absolute_path )

    command = shlex.split( command_name )
    command_line_interface = subprocess.Popen( 
          command, stdout=subprocess.PIPE, cwd=absolute_path )

    output = command_line_interface.communicate()[0]
    print( output )

    if command_line_interface.returncode != 0:
        raise RuntimeError( "A process exited with the error '%s'..." % ( 
              command_line_interface.returncode ) )

def main():
    FILENAMES_MAPPING = \
    [
        (r"F:\\SublimeText\\Data", r"README.MD", r"README.md"),
        (r"F:\\SublimeText\\Data\\Packages\\Alignment", r"readme.md", r"README.md"),
        (r"F:\\SublimeText\\Data\\Packages\\AmxxEditor", r"README.MD", r"README.md"),
    ]

    for absolute_path, oldname, newname in FILENAMES_MAPPING:
        run_command( absolute_path, "git mv '%s' '%s1'" % ( oldname, newname ) )
        run_command( absolute_path, "git add '%s1'" % ( newname ) )
        run_command( absolute_path, 
             "git commit -m 'Normalized the \'%s\' with case-sensitive name'" % (
              newname ) )

        run_command( absolute_path, "git mv '%s1' '%s'" % ( newname, newname ) )
        run_command( absolute_path, "git add '%s'" % ( newname ) )
        run_command( absolute_path, "git commit --amend --no-edit" )

if __name__ == "__main__":
    main()
person user    schedule 29.09.2019