git rebase: «ошибка: невозможно указать файл»: разрешение запрещено »

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

Так я и сделал:

git rebase -i HEAD~2

Это дало мне мой редактор, где я выбрал более ранний коммит и раздавил более поздний. Когда я спас, Git сказал:

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

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

Сейчас:

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

Что произошло!? Как мне это исправить?

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

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

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

git rebase --abort

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

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

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

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

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

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

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

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

Я только что наткнулся на эту ветку ответов - эта ошибка является фиктивной ошибкой. # Ошибка: невозможно указать 'reddit / app / views / links': отказано в разрешении

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

После закрытия редактора - я снова запустил git merge и boom, все заработало.

Что за бессмысленная ошибка :(

при использовании vscode убить терминал и открыть новый. еще может закрыть терминал тоже

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

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

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

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

Если IDE, которую вы используете (в случае, если вы ее используете), возможно, тоже мешает. Вот что случилось со мной при использовании QtCreator.

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

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

1. В ветви B создайте md-файл, используя Atom, отредактируйте его, сохраните и подтвердите.
2. Переключитесь на ветку A, откройте новые коммиты с сервера.
3. Попробуй Switch back, Opps, там написано: «ошибка: невозможно указать« файл »: разрешение запрещено».

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

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

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

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

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

У меня только что было это под Win 7.

$ git stash pop error: невозможно указать «parentFolder / subfolder»: ошибка в разрешении: невозможно определить «parentFolder / subfolder»: разрешение отклонено

Диагноз:

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

2> Используйте «Process Explorer» -> Find -> Find handles and Dlls -> поместите туда имя «subfolder» и выполните поиск.

Результат: Оказывается, что XMLSpy открыл там один из XML, закройте XML Spy и попробуйте снова запустить stash pop, теперь он работает.

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

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

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

Поэтому я открыл обычное окно с правами администратора, перешел в каталог и выполнил

attrib -R /S

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

Я согласен с приведенными выше ответами «Закрыть Visual Studio».

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

мерзавец

и ошибка «невозможно указать имя файла » исчезла. Возможно, это связано с расширением Visual Studio, которое позволяет процессу оставаться открытым даже после закрытия.

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

Альтернативное решение, а не закрытие всех приложений, которые могут блокировать каталог, как это делает любой другой ответ, состоит в том, чтобы использовать утилиту, которая разблокирует файлы / каталог, не закрывая все. (Ненавижу необходимость перезапускать Visual Studio)

LockHunter - это то, что я использую: https://lockhunter.com/ Возможно, есть и другие, но этот отлично сработал для меня.

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

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

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

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

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

#!/bin/sh

set -e

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

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

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

Если у вас открыт инструмент слияния Meld , закройте его. Он блокирует перезапись файла.

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

В моем случае у меня был запущен сервер разработки веб-пакетов.

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

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

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

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

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

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

Grunt Serve Command - Yeoman.I / O
http://yeoman.io/learning/

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

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

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

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

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

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