Git rebase: "error: can not stat 'file': Permission denied"

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

Итак, я сделал:

git rebase -i HEAD~2

Это дало мне мой редактор, где я решил выбрать более раннюю фиксацию и сквош позже. Когда я сохранил, git сказал:

error: не может stat 'filename': Permission denied

Не удалось применить sha1 для последующей фиксации... начальная строка текста для этой фиксации

Сейчас:

  • Ни один фиксатор не появляется, когда я делаю git log.
  • git status говорит мне, что я "не в настоящее время в любом филиале".
  • Один файл указан как измененный, так и в индексе, и два файла перечислены как не проверенные. У моего первого коммита был только один файл (я думаю), и у моей второй фиксации была хорошая дюжина.

Что случилось!? Как это исправить?

ОТВЕТЫ

Ответ 1

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

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

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

git rebase --abort

Вы можете попытаться использовать git apply и знать, что именно совершил git, прежде чем делать git rebase --continue, но, честно говоря, я бы не рекомендовал этого. В большинстве случаев, когда я видел это, у меня была вероятность, что что-то случайно пропущено или испортилось.

Ответ 2

Попробуйте закрыть любые программы с открытой папкой, такие как редакторы, окна проводника, командные подсказки и программы FTP. Это всегда исправляет проблему для меня в Windows.

Ответ 3

Просто закройте свою среду IDE (VISUAL STUDIO/ATOM и т.д.). Это может работать

Ответ 4

Когда я вижу это на своей машине, это хуже, чем просто "какой-то процесс имеет открытый файл". Фактическое владение файлом доводится до такой степени, что я (работающий как администратор) может получить к нему доступ только после перезагрузки.

Ближайшее, что я могу сказать, IIS является частью проблемы. Если я переключаюсь между двумя основными ветвями, требующими большого количества файлов для изменения, git удалит файл или каталог (обычно DLL), в то время как IIS пытается что-то сделать с ним. На этом этапе процесс IIS автоматически перезаписывает файл на диске с той версией, которая заблокирована и, по-видимому, не принадлежит никому.

Остановка IIS в этот момент не выполняется. Лучшее, что я нашел, это перезагрузить компьютер и не забывать останавливать IIS перед тем, как переходить к основным разделам в будущем.

Я знаю, что на самом деле не отвечает на вопрос, но может быть полезен другим.

Ответ 5

Я просто наткнулся на эту цепочку ответов - эта ошибка является такой ошибкой Bogus. # error: не может stat 'reddit/app/views/links': Permission denied

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

Как только вы закрываете редактор, я снова запускал "git merge" и стрелял, он работал.

Какая бессмысленная ошибка: (

Ответ 6

В Windows это может быть процесс TortoiseGIT, который блокирует эти файлы. Откройте диспетчер задач и завершите процесс TGitCache.exe.

Ответ 7

Если среда IDE, используемая вами (в случае ее использования), возможно, тоже мешала. Что случилось со мной при использовании QtCreator.

Ответ 8

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

Ответ 9

Использование SourceTree в Win 10 устраняет проблему, закрывая редактор Atom.

Ошибка воспроизведения:

  • В ветке B создайте md файл, используя Atom, отредактируйте его, сохраните и зафиксируйте.
  • Перейдите в ветвь A, вытащите новые коммиты с сервера.
  • Попробуйте переключиться назад, Opps, он говорит: "error: can not stat" file ": Permission denied".

Ответ 10

Это случается со мной в Windows иногда

ошибка: невозможно указать 'имя файла': в доступе отказано

Чаще всего у меня открыто несколько экземпляров bit bash, и один из экземпляров git bash находится в каталоге, который не существует в удаленной ветки, из которой я извлекаю.

Закрытие всех экземпляров git bash, кроме одного, решает проблему для меня.

Ответ 11

Это часто происходит, когда у вас есть предварительная обработка программного обеспечения/приложений, наблюдающих за проектом, таких как Prepros или Codekit. Кроме того, Atom и Sublime (и даже Notepad ++) могут привести к тому, что это произойдет, если файл в проекте в настоящее время редактируется.

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

Ответ 12

У меня была аналогичная проблема. Но это было очень просто решить. На машине с Windows у моего проводника файлов была открытая папка, которая существовала в одной ветке, но не в другой, которую я проверил. Закрытие проводника файлов разрешило проблему.

Ответ 13

Я только что получил это под Win 7.

$git stash pop error: не может stat 'parentFolder/подпапка': Permission denied error: не может stat 'parentFolder/подпапка': Permission denied

Диагноз:

1 > Я пошел в подпапку и там, и я не смог ее удалить!

2 > Используйте "process explorer" → Найти → Найти дескрипторы и Dll → введите там имя "подпапки" и выполните поиск.

Результат: выясняется, что XMLSpy открыла один из xml там, закройте XML-шпион и снова попробуйте стафф-поп, теперь он работает.

Ответ 14

Моя встреча с этой проблемой была вызвана моим редактором Intellij. Как часть внутренних элементов управления версиями, он прошел и заблокировал все скрытые файлы git. (По разным причинам я не использовал плагин git, который поставляется с Intellij...)

Итак, я открыл обычное окно dos в качестве администратора, изменил его в каталог и выполнил

attrib -R /S

Это удалило блокировку файлов, и после этого все сработало, и я смог синхронизировать свои изменения с помощью клиента Windows GitHub.

Ответ 15

Я согласен с приведенными выше ответами "Close Visual Studio".

Однако, еще один шаг, который я должен был сделать, даже после того, как я закрыл Visual Studio, - это вручную убить "devenv.exe процесс Visual Studio в Task Explorer, После того, как я это сделал, я снова смог запустить gitbash:

git pull

и ошибка "can not stat filename" исчезла. Возможно, это связано с расширением Visual Studio, которое продолжает работу дольше даже после закрытия.

Ответ 16

У меня была эта проблема. Дело в том, что если вы открыли файл, который был удален\заменен после rebase (у вас была ветка, у которой больше нет этого файла), система git развращает. Поэтому я закрыл все открытые файлы, а затем попытался проверить на какой-либо другой ветке

Ответ 17

Если вы используете webpack, выключите его. Выключите свою IDE также. Должно работать нормально после этих вещей.

Ответ 18

Такая же проблема в Windows 10 64 Bit, работает Git Bash версия 2.9.0.windows1 Использование Atom в качестве моего редактора.

Это сработало для меня: я добавил папку программного обеспечения Git (для меня это C:\Program Files\Git) для исключений для Защитника Windows.

После того, как было добавлено исключение, git checkout 'file' работал нормально.

Ответ 19

Эта ошибка также может быть вызвана тем фактом, что файлы по-прежнему "заблокированы" из-за предшествующих действий git. Это связано с тем, как работает файловый уровень Windows. Я когда-то прочитал это хорошее объяснение, но не могу вспомнить, где.

В этом случае, однако, поскольку это в основном условие гонки, все, что вам нужно сделать, это продолжить прерванный процесс переадресации. К сожалению, это происходит со мной все время, поэтому я написал этот небольшой опасный помощник, чтобы сохранить мои перестановки:

#!/bin/sh

set -e

git checkout .
git clean -df
git rebase --continue

Если вы хотите быть более уверенным, вы можете использовать git rebase --edit-todo, чтобы проверить, действительно ли следующая фиксация будет применена - это тот, который раньше не применялся. Используйте git clean -dn, чтобы не удалять важные файлы.

Ответ 20

Случилось со мной, когда в окнах при использовании Photoshop: Когда я сохранил изображение, а затем переключился на ветку (оставив фотошоп с открытым изображением), я получил ошибку git. Закройте изображение в фотошопе и повторите попытку

Ответ 22

Убив процесс w3wp.exe, связанный с хранилищем, исправил это для меня.

Ответ 23

Произошло со мной в Windows во время перебазирования внутри встроенного терминала IntelliJ. Я заметил, что у меня есть экземпляр клиента Git bash, работающий параллельно.

Закрытие Git Bash решило проблему.

Ответ 24

Мы разрешили проблемы с правами, щелкнув правой кнопкой мыши файл sh.exe в Program Files и установив "Запуск от имени администратора" на вкладке "Безопасность".

Ответ 25

Я получил эту ошибку, когда мой VS1013 находился в таргетинге на ветку 8.1, и я пытался проверить ветвь 8.0. Мне нужно было вернуться к VS и разрешить его UpdateAll. Затем я смог проверить ветвь 8.0 без ошибок.

Ответ 26

Я тоже был на машине Windows, используя Git Shell, когда я столкнулся с той же ошибкой.

Однако в то время, когда я открывал несколько терминалов Git.

Первый терминал получил сообщение об ошибке, о котором вы писали выше, а другой терминал ранее выполнял команду терминала grunt serve от yoman (см. ниже). Второй терминал должен оставаться открытым для размещения локального экземпляра сервера.

Выключение всех окон терминала, выполняющих текущие процессы, может привести к ошибке.

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

Командная команда Grunt Serve - Yeoman.I/O
http://yeoman.io/learning/

Ответ 27

Я просто столкнулся с этой проблемой. Не было ответов на эти ответы для меня.

Закончилось создание пакетов nuget, которые я добавил на ветку, которая, как только вернулась к мастер-ветке, вроде бы не существовала. Как только я сделал слияние, он сказал бы, что newtonsoft... xml не смог установить. Я бы пошел в файл, о котором идет речь, и откройте его, но Windows отказала в ошибке, заявив, что не может найти файл (хотя я и смотрю на него)

Как я решил, это был щелчок правой кнопкой мыши, удалив файл (который работал, но я не смог открыть его, потому что окна не могли его найти?) и попытаться снова объединиться, и он решил проблему.

Очень странно.

Надеюсь, это поможет кому-то позже.

Ответ 28

Я вышел из своего текстового редактора, который обращался к каталогам проекта, а затем попытался слить его на главную ветку и работал.

Ответ 29

Такая же проблема, но с использованием SourceTree (или любого другого клиента git). Я добавляю свой ответ, поскольку ни один из ответов не соответствует моему делу.

Изменение ветки с "develop" на "main" изменяет фактические файлы и подпапки вашей локальной папки. Может случиться так, что папка, которая не существует в "хозяине", не полностью стерта, и окна верят, что вы только потеряли права доступа (даже если вы админ). При слиянии с основным для разработки клиент git пытается получить доступ к папке. Без прав доступа он возвращает указанную ошибку.

  • Переключение с одной ветки на последнюю может решить проблему, а затем назад к мастеру (дважды проверьте, действительно ли папки/файлы локально удален).
  • Закрытие клиента и/или вашего редактора не устраняет проблему!
  • Перезагрузка помогает, но это пустая трата времени (IMHO).

Ответ 30

В моем случае файл представляет собой оболочку script (*.sh file), предназначенную для развертывания нашего проекта на локальном сервере разработки для моих разработчиков.

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

Оболочка script запускает один исполняемый файл, а затем разрешает запуск этого исполняемого файла; поэтому script все еще работает; поэтому у моей оболочки все еще есть script open; поэтому он заблокирован.

I Ctrl+C 'd, чтобы убить script (так что теперь мой локальный dev-сервер больше недоступен), теперь я могу свободно проверять.