Спецификатор пути не соответствует ни одному файлу
У меня есть репозиторий, в котором я могу без проблем зафиксировать любой файл. Однако есть единственный файл Funder.php, который, когда я пытаюсь выполнить фиксацию, сообщает мне об ошибке, как:
Я новичок в этом, поэтому мне было интересно, может ли кто-нибудь помочь?
Это ошибка, которую вы получаете при попытке запустить
Но еще не поставили; Другими словами, Git еще не сказал об этом. Скорее всего, вот что происходит. Пробег
Затем попробуйте совершить.
Попробуйте использовать двойные кавычки, если вы работаете в ОС Windows
Моя проблема была во временном файле резервной копии слова, начинающемся с ~ $, имя файла было ~ $ . Docx.
Я не уверен, что происходит - мой текстовый документ подбирается GIT с использованием Pycharm, поэтому я предполагаю, что в какой-то момент я редактировал при работе с GIT.
Мне пришлось создать временный файл с тем же именем, зафиксировать, а затем удалить файл.
В моем случае проблемный файл был отмечен знаком --skip-worktree . Это можно легко проверить с помощью
В git commit я снова использовал двойные кавычки. Это вызывало ту же ошибку.
Приведенная выше команда выдавала ту же ошибку
Я изменил это на
Это устранило мою проблему.
Я испытал это, по ошибке создав ветвь в другом репо на BitBucket, поэтому убедитесь, что вы находитесь в правильном репо и что ветка существует там.
У меня была аналогичная проблема с фиксацией удаленных файлов с помощью SourceTree на Mac. В одном из проблемных файлов были акценты (áéíóú . ). Чтобы решить эту проблему, мне пришлось использовать терминал, а не SourceTree
У меня была такая же проблема с файлом .entitlements, удаление существующего файла и его повторное добавление сработали для меня.
Моя проблема заключалась в том, что я копировал / вставлял всю строку фиксации, и в ней были специальные символы, которые казались обычными символами в консоли (например, умные кавычки вместо обычных). Как только я вставил их в текстовый редактор, я увидел их, исправил, и это сработало.
В XCode 7.3 я переименовал рассматриваемый файл в FooBar.foo.tmp, а затем зафиксировал, как только XCode / git добавил этот новый файл и установил удаление старого. Как только я совершил коммит, я переименовал его обратно (в XCode). Теперь все нормально. Такова жизнь.
У меня была такая же проблема со словом «сертификат» в качестве имени пакета . когда я переименовал пакет в «сертификаты», он просто работал . странно ..
iOS 9.2.1, Xcode 7.2.1, ARC включен
Загляните в это при изменении файла «contents.json» для моего каталога ресурсов LaunchImage. Вы можете использовать команды терминала, указанные в качестве ответа, но попробуйте этот более простой способ .
Контроль версий -> Обновить статус
Надеюсь это поможет. Ура!
У меня была аналогичная проблема, но я ее исправил. Я должен был использовать "" вместо "" в командной строке Windows
git commit "Your Commit Message" //Throws an error: pathspec '3.
git commit -m "Your Commit Message" //No error thrown
У меня была такая же проблема. просто замените "одинарные кавычки начального комментария" на двойные кавычки ""
У меня был этот сценарий неудачной фиксации из-за переименованного каталога.
Это был изначально созданный каталог с ошибкой использования заглавных букв:
Фиксация завершилась ошибкой: pathspec "application / templates / lists / index.html" не соответствует ни одному файлу (файлам), известным git.
После некоторого чтения моя стратегия заключалась в том, чтобы извлечь файл и затем снова добавить его. Я отключил подозрительный файл
Обратите внимание, git status показывал здесь только каталог . Не файл.
Затем я добавил обратно с исправленным именем каталога (я использовал только путь для добавления, следуя указаниям из git status).
После этого моя фиксация прошла успешно. Я не уверен, что это был идеальный метод, но в моем случае он устранил ошибку фиксации.
Проблема: я добавил файл, который позже переименовал.
Решение:
git reset HEAD oldFileName.file
git add newFileName.file
Наконец, я решил сделать резервную копию классов в пакете, в котором был проблемный файл, в отдельной папке на моем жестком диске, затем я удалил файлы из исходной папки и в терминале сделал:
Затем воссоздал удаленный пакет через Android Studio, скопировал и вставил туда мои классы. После этого я смог совершить фиксацию без каких-либо проблем.
Файловая система Windows в основном нечувствительна к регистру, поэтому вы не можете переименовать файл, просто изменив его регистр. Вместо этого вам придется использовать временное имя между ними.
Решение: переименуйте файл обратно в исходный, затем переименуйте его в другое имя, а затем вернитесь к файлу с правильными заглавными буквами. Git больше не выдаст ошибку.
Я случайно добавил более 9000 фотографий в папку своего проекта. И совершил их. Затем удалил их с диска. Совершенные.
Я проверил размер файлов на диске и увидел, что действительно папка .git занимает 12 Гб.
Как удалить фотографии оттуда? Я попытался git rm , но не смог:
Потому что я уже удалил их с диска, но они все еще находятся в папке .git .
Я пытался добавить public/photos в .gitignore :
Но нет результата. Конечно, я мог hard reset head в тот момент, когда у меня не было столько ненужных фотографий в моем проекте. Но с тех пор я много раз совершал и делал много изменений в коде.
В вашем случае используйте git filter-branch вместо git rm .
git rm удалит файлы в том смысле, что они больше не будут отслеживаться git, но это не удалит старый коммит объекты, соответствующие этим изображениям, и поэтому вы все равно будете застревать с нажатием предыдущих коммитов, которые соответствуют 12 ГБ изображений.
git filter-branch , с другой стороны, может также удалять эти файлы из всех предыдущих коммитов, избавляя от необходимости подтолкнуть любого из них.
После завершения ветки фильтра убедитесь, что не был потерян какой-либо непреднамеренный файл.
Теперь добавьте правило .gitignore
Теперь сделайте толчок
Проверьте этот , это и это для получения дополнительной помощи. Чтобы быть в безопасности, я бы посоветовал вам создать резервную копию репозитория в вашей системе, прежде чем приступить к выполнению этих инструкций.
Шаг 1
Добавьте имена файлов в свой файл .gitignore .
Шаг 2
Шаг 3
Большое спасибо @mu.
Очень простой ответ.
Шаг 1:
Сначала добавьте ваши неотслеживаемые файлы, которые вы хотите удалить, используя git add . или git add
Шаг 2.
Затем легко удалите их, используя команду git rm -f здесь rm = remove и -f = forcely.
сделал работу, Он восстановил удаленные файлы, используя rm вместо git rm
Сначала я сделал проверку последнего хэша, но я не верю, что это необходимо.
Эти цепочки работают в моем случае:
Был подтверждающий git-диалог. Вы должны выбрать вариант «у».
Git: невозможно проверить ветку - ошибка: pathspec '…' не соответствует ни одному файлу (файлам), известным git
Я только начал изучать GIT. Следуйте их руководству.
Вот в самом начале я застрял с такой ошибкой:
Вот скриншот моей процедуры и команд:
Что я здесь делаю не так?
- Не обязательно ваш случай, вы можете увидеть это с помощью git 1.8.5 на первом git add , в пустом репо. Это исправляется: см. Мой ответ ниже
Файлы не существуют, поэтому их нельзя добавить. Сначала убедитесь, что файлы были созданы.
Чтобы добавить файл в git, он должен существовать. git add не создает файл, а сообщает git, что он должен добавить его в текущую ветку, в которой вы находитесь, и отслеживать ее.
В настоящее время у вас нет отслеживаемых файлов, как видно из вашего git status команда. Чтобы отслеживать все файлы из мой проект каталог, сделайте git add my-project/* . Это добавит все файлы из этого каталога.
Далее, если у вас нет желаемого file.txt, просто создайте текстовый файл и запустите git status . Это должно показать вам, что у вас нет отслеживания file.txt файл, который впоследствии можно добавить в git, используя git add file.txt .
См. Commit 64ed07c Нгуен Тхай Нгок Дуй ( pclouds ):
Похожие вопросы
add : не жалуйтесь при добавлении пустого корня проекта
Это поведение было добавлено в 07d7bed ( add : не жалуйтесь при добавлении пустого корня проекта - 28.04.2009, git 1.6.3.2)
затем сломан 84b8b5d (удалить match_pathspec() в пользу match_pathspec_depth() - 14.07.2013, git 1.8.5).
Мы пытаемся предупредить пользователя, если один из его путей не привел к совпадению, поскольку это могла быть опечатка. Однако мы отключаем предупреждение, если путь указывает на существующий файл, поскольку это означает, что это не опечатка, а просто пустой каталог.
К сожалению, file_exists() тест был нарушен в одном частном случае: путь к корню проекта просто "".
Этот патч обнаруживает этот особый случай и действует так, как будто файл существует (что должно быть, поскольку это корень проекта).Видимый пользователем эффект заключается в следующем:
В грядущем git 1.9 / 2.0 (первый квартал 2014 г.) это снова молчаливый отказ.
Но возникла следующая ошибка:
фатальный: pathspec 'AppName / View' не соответствует ни одному файлу
Как видите, команда прерывается между представлением и контроллерами, потому что есть пробел.
Мне просто пришлось заключить свой путь в двойные кавычки. Обычно в этом нет необходимости, но когда у вас есть пробелы, вам нужно.
У меня была та же проблема, потому что имя файла уже добавлено с расширением .txt, а вы явно добавляете дополнительный .txt. Вы можете попробовать это:
Чтобы добавить файл в git, он должен существовать. git add не создает файл, а сообщает git, что он должен добавить его в текущую ветку, в которой вы находитесь, и отслеживать ее. Итак, вы должны создать новый файл в командной строке:
После этого вы добавляете:
Я тоже зациклился на этом. Решение: а) Сначала создайте любой текстовый файл, скажем "Readme.txt"
б) Скопируйте этот текстовый файл в локальное репозиторий git (папку), например - C: / store
c) Перейдите в командную строку Windows, если вы находитесь в Windows (введите «cmd» в строке поиска, когда вы нажмете кнопку окна)
г) перейдите в локальное репозиторий git. введите ** echo hello> Readme.txt ** ---> C: \ admin \ store> echo hello> Readme.txt
echo hello - это команда dos, которая показывает текст состояния вывода на экран или в файл.
Файл не найден, потому что git add создает ваш файл в корневом каталоге, но на самом деле он не создает файл, а сообщает git, чтобы он добавил его в текущую ветку, в которой вы находитесь (добавляет файлы из рабочего каталога в промежуточную область) и отслеживает его с помощью git status команда. Так,
сначала создайте файл .txt и правильно укажите путь! пусть есть
(Не только для этого, для любой команды git для изменения промежуточной области напишите полный путь к имени файла с переадресацией косой черты после команды)
если ваш файл находится на рабочем столе, то
Ну вот! Очень простой. Необходимо вручную поместить файл .txt в указанную папку pwd .
suumapat @ SUUMAPAT-IN MINGW64 ~ / newproject (master) $ git add abc.txt фатальный: pathspec 'abc.txt' не соответствует ни одному файлу
suumapat @ SUUMAPAT-IN MINGW64 ~ / newproject (master) $ dir
suumapat @ SUUMAPAT-IN MINGW64 ~ / newproject (master) $ pwd / c / Users / suumapat / newproject
suumapat @ SUUMAPAT-IN MINGW64 ~ / newproject (master) $ dir abc.txt
suumapat @ SUUMAPAT-IN MINGW64 ~ / newproject (master) $ git add abc.txt
У меня была такая же проблема, но с файловой системой Windows. Вот мое решение, которое сработало.
из каталога проекта git. Вот именно то, что отображалось в текущем каталоге.
D: \ Projects \ ReactNative \ project> git add "scr / \ components / \ validate.js"
В git вводится файл validate.js. Он находился в каталоге проекта. Этот каталог был src \ components.
У меня была такая же проблема. Подтвердите каталог с файлами. После перемещения моего файла в правильный каталог он работает.
Просто укажите путь к файлу при добавлении файла в команду git add, у меня это работает
$ git add mainFolder /. / file.extension
Примечание: mainFolder будет папкой внутри вашего репо.
Эта ошибка возникает из-за того, что файл, который вы добавляете в репозиторий, не создается. Сначала создайте файл, а затем добавьте его в область подготовки:
Обработка ошибок в Power Query с помощью попытки в противном случае - советы и рекомендации по Power BI №32
Я пытаюсь загрузить (объединить) несколько файлов Excel в Power BI (версия от октября 2019 г.). В каждом файле всего 1 лист. Каждый лист имеет 1 диапазон, и каждый диапазон имеет одинаковую схему для всех файлов. (Хотя названия листов разные.) Имя образца листа - «200704».
- Получить данные \ папку \ подключить
- укажите путь к папке
- Объединить и загрузить
- выберите один из файлов в качестве моего файла образца; щелкните имя файла как мой Параметр1; нажмите ОК
После того, как я нажму «ОК», курсор немного покрутится, а затем остановится. Ничего не произошло. Итак, я перехожу в Edit Queries \ Edit Queries. В моем запросе данных есть предупреждающий символ, который гласит:
Произошла ошибка в запросе «Преобразовать файл». Expression.Error: ключ не соответствует ни одной строке в таблице.
Подробности: Ключ = Элемент = 200704 Вид = Лист Таблица = [Таблица]
Если это поможет, Power BI сгенерирует для меня 5 запросов со следующей структурой:
- Преобразовать файл из данных [2]
- Вспомогательные запросы [3]
- Параметр1 (образец файла)
- Образец файла
- Преобразовать файл
- Файл-образец преобразования
- Другие запросы [1]
- данные
Интересно, что если это помогает диагностировать проблему, если я установил образец файла = Первый файл или если я вручную установил образец файла для своего первого файла, в диалоговом окне выдается следующая ошибка, но она не показывает, какой запрос ошибочен. когда я пытаюсь просмотреть / отредактировать запрос.
Не удалось сохранить изменения на сервере. Возвращена ошибка: «Ошибка OLE DB или ODBC: [Expression.Error] Ключ не соответствует ни одной строке в таблице ..».
И, конечно же, когда я пытаюсь загрузить этот файл (или любой файл в папке, если на то пошло) индивидуально (через соединение с Excel), он загружается успешно. Итак, что-то должно быть не так с кодом M в моем подключении к папке.
- Вы пытались выяснить, есть ли что-нибудь в вашем 200704 лист отличается от любых других листов в папке? Структура, форматирование и т. Д.
Для сравнения вот мой бывший (неверный) M-код:
А вот мой новый (правильный) код:
Обратите внимание на шаг «Удаленные столбцы» в новом шаблоне запроса. Это «секретный соус» к ключевой проблеме. Также обратите внимание, что я сохранил все шаги по умолчанию после моего шага «Данные» (т.е. «Продвинутые заголовки» и «Измененный тип») в моем шаблоне запроса. Это потому, что все мои листы имеют одинаковую схему. Если бы это было не так, мне пришлось бы переместить эти шаги в обычный запрос.
Многим пользователям ПК под управлением ОС Windows, не говоря о разработчиках, знакомы проблемы при работе с длинными (более 260 символов, MAX_PATH) путями файлов или каталогов.
Приложения Win API
В приложениях, которые используют Win API для работы с файлами, рецепт избавления от ограничения MAX_PATH был известен с незапамятных времён – необходимо было использовать Unicode версию функции с окончанием «W» для работы с директорией или файлом и начинать путь с префикса \\?\. Это давало возможность использовать пути длинной до 32767 символов.
В Windows 10 (1607) поведение функций для работы с файлами изменилось: появилась возможность отключить проверку ограничений MAX_PATH на уровне системы.
Для работы с каталогами: CreateDirectoryW, CreateDirectoryExW, GetCurrentDirectoryW, RemoveDirectoryW, SetCurrentDirectoryW. И для работы с файлами: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.
Это избавляет от необходимости использовать префикса \\?\ и потенциально даёт шанс приложениям, работающим напрямую или косвенно через Win API, получить поддержку длинных путей без необходимости их пересборки. Как активировать эту возможность описано в конце статьи.
Тут поддержку длинных путей анонсировали ещё в ноябре 2015 года. Видимо сказалось Open Source природа проекта и отсутствие строгой необходимости обеспечения обратной совместимости.
Вот тут можно посмотреть пример.
Как включить поддержку длинных путей в Windows 10 (1607)
Эта возможность по умолчанию отключена. Это объясняется тем, что данная функция является экспериментальной, и имеется необходимость дорабатывать различные подсистемы и приложения для полной поддержки.
Включить встроенную поддержку длинных путей можно создав или изменив следующий параметр системного реестра: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem Параметр LongPathsEnabled (Тип: REG_DWORD) 1 – соответствует значению включено.
Или через групповые политики (Win+R\gpedit.msc) Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths.Оно же в локализованном варианте: Конфигурация компьютера > Административные шаблоны > Система > Файловая система > Включить длинные пути Win32.
Далее источники расходятся во мнении относительно манифеста (или я неправильно понял, но на данный момент проверить не имею возможности). Например, в документации MSDN написано, что манифест можно использовать в качестве альтернативного способа активации поддержки длинных путей в отдельных приложениях, а в блоге MSDN указано, что это является вторым обязательным шагом после активации в политиках.
Но они сходятся в формате задания данной опции:
С CMD, к сожалению, это не сработает, на данный момент, из-за особенностей работы с путями, а в PowerShell должно всё заработать.
На этом мой небольшой пятничный пост заканчивается, оставив за рамками вопросы полноты реализации поддержки длинных путей в Windows 10 (1607), или работоспособность при использовании различных комбинаций редакций Windows, файловых систем и API. По мере поступления новых фактов и результатов экспериментов пост будет обновляться.
Популярные теги
Похожие вопросы
Читайте также: