Как это исправить
Если вы можете попросить кого-то другого - например, на Linux - переименовать проблемный c файл и выполнить фиксацию, это сделает работу. Или просто разверните виртуальную машину с Linux на ней, клонируйте, исправьте имя (и всех его пользователей), зафиксируйте и отправьте обновление обратно.
Проблема: Windows
Windows не может обрабатывать ни один файл с именем AUX. Вы не можете назвать файл PRN, CON или COM1.
error: invalid path 'soft/android-app/app/src/main/java/com/inti/bleapp/<strong>Aux</strong>.java'
Вы можете возразить: это не файл с именем AUX. В худшем случае это файл с именем Aux.java.
Но для Windows файл с именем AUX:
- Windows регистронезависим, поэтому
aux, Aux, auX и так далее - это просто способ написания AUX. - Windows по-прежнему думает о файлах с именами из восьми точек и трех:
FILENAME.EXT. Конечно, кажется, что все используют длинные имена, и вы можете иметь файлы с именем foo.data.jpg, если хотите. Но глубоко в своем сумасшедшем прошлом Windows использовал имена 8.3, и настаивает на поддержке программ, которые все еще используют имена 8.3, поэтому все файлы где-то получают имя 8.3, а Aux.java получает 8.3 имя, которое начинается с AUX, и наличие расширения не поможет вам обойти запрещенное имя файла.
Проблема не только в Windows
В MacOS может радостно указывать и смеяться, но у MacOS тоже есть проблемы.
Linux люди могут и имели в прошлом сохраненные файлы под такими именами, как оба ip.h и IP.h в том же каталоге. Идея заключалась в том, чтобы определить вариант с прямым порядком байтов для заголовков IP для TCP / IP в нижнем регистре ip.h и определить вариант с прямым порядком байтов в верхнем регистре IP.h. Сворачивание регистра, которое и Windows, и MacOS делают по умолчанию, здесь доставляет нам неприятности. способы использования UTF-8. Файловые системы Linux могут хранить любой из способов, а Git просто возьмет любой способ хранения и поместит его в имя зафиксированного файла. Но MacOS требует одну нормализованную форму имени файла, и это вызывает те же проблемы.
Что Git требует (но не имеет)
Git требует пути чтобы справиться с этим.
Git имеет ли"разреженную проверку". Разреженная проверка позволяет вам определить набор файлов, которые будут извлечены из некоторой фиксации, и другие файлы, которые не будут извлекаться - это будет go в Git индекс , как обычно, но не появится в рабочем дереве.
Вы можете использовать разреженную проверку, чтобы проверить эту фиксацию без извлечения файла soft/android-app/app/src/main/java/com/inti/bleapp/Aux.java вообще. Что ж, возможно, это нормально, но у вас не будет файла.
Фактически, вы уже этого не сделали, как сказано в последнем сообщении:
предупреждение: Клонирование выполнено успешно, но проверка не удалась.
Когда проверка не удалась, все другие файлы должны быть доступны в вашем рабочем дереве. Просто этот soft/android-app/app/src/main/java/com/inti/bleapp/Aux.java этого не сделает. Если вы можете выполнить работу без него, вы можете смоделировать разреженную проверку, запустив:
git update-index --skip-worktree soft/android-app/app/src/main/java/com/inti/bleapp/Aux.java
Что Git должно - это некоторые инструменты для более продуктивной работы с этими файлами. В частности, должно быть возможно (и это возможно, если вы погрузитесь в глубины Git), чтобы извлечь файл под с каким-то другим именем , а затем добавить переименованный файл под оригинальное название при необходимости. Должно быть возможно (и возможно, но не с помощью какой-либо разумной команды для пользователя) переименовать файл и зафиксировать, после чего вы можете проверить новый коммит и работать с файлом с именем, которое вы ОС не ненавидит.
Все это возможно , потому что Git на самом деле делает новые коммиты из того, что находится в его индексе, а не из того, что находится в вашем рабочем дереве. Нет жесткого требования, чтобы имена в индексе совпадали с именами в вашем рабочем дереве. Но все команды Git, ориентированные на пользователя - git checkout, git restore и git add являются основными - делают , сегодня предъявляют это требование.