Ответ 1

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

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

Изменить: Также возможно, что файл был создан только в рабочем дереве без добавления в репо. В этом случае не просто удалите локальный файл, а скорее:

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

Ответ 2

Самый безопасный и простой способ, вероятно, снова будет замалчиваться:

git stash -u             # This will stash everything, including unstaged files
git stash pop [email protected]{1}  # This will apply your original stash

Затем, если вы довольны результатом, вы можете позвонить

git stash drop

чтобы удалить ваш "безопасный" тайник.

Ответ 3

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

Лучший способ сделать это - конвертировать тайник в ветку. Когда это ветка, вы можете нормально работать в git, используя обычные методы/инструменты, связанные с веткой, которые вы знаете и любите. Это на самом деле полезный общий метод работы с записями, даже если у вас нет указанной ошибки. Это хорошо работает, потому что на самом деле это кошелек под крышками (см. PS).

Преобразование тайника в ветку

Ниже создается ветвь, основанная на HEAD, когда был создан stash, а затем применяет тайник (он не фиксирует его).

git stash branch STASHBRANCH

Работа с "ветвью штампа"

То, что вы делаете дальше, зависит от взаимосвязи между косой чертой и где ваша целевая ветка (которую я назову ORIGINALBRANCH) теперь.

Вариант 1 - Обычно разблокировать ветвь штемпеля (много изменений с момента заполнения)

Если вы внесли много изменений в свой ORIGINALBRANCH, то вы, вероятно, лучше всего относитесь к STASHBRANCH, как к любой локальной ветке. Зафиксируйте свои изменения в STASHBRANCH, перезапустите его на ORIGINALBRANCH, затем переключитесь на ORIGINALBRANCH и переустановите/объедините изменения STASHBRANCH над ним. Если есть конфликты, то обрабатывайте их нормально (одним из преимуществ этого подхода является просмотр и разрешение конфликтов).

Вариант 2 - Reset исходная ветвь для соответствия тире (ограниченные изменения с момента заполнения)

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

git symbolic-ref HEAD refs/heads/ORIGINALBRANCH
git reset

Фон

Штампы коммиты любят ветки/теги (не патчи)

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

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

PPS, вам может понадобиться этот метод после использования stash с --patch и/или --include-untracked. Даже без изменения рабочих каталогов эти параметры иногда могут создавать кошельки, которые вы не можете просто применить обратно. Я должен признать, что не понимаю, почему. См. http://git.661346.n2.nabble.com/stash-refuses-to-pop-td7453780.html для обсуждения.

Ответ 4

Решение: вам нужно удалить указанный файл, а затем попытаться снова нажать "всплывать" / "применить", и он должен пройти. Не удаляйте другие файлы, только те, которые указаны в этой ошибке.

Проблема: Git иногда отстой. При запуске git stash -u он включает в себя неископанные файлы (круто!), Но не удаляет эти необработанные файлы, а не умеет знать, как применять скрытые не проверенные файлы поверх остатки (не здорово!), что действительно делает параметр -u довольно бесполезным.

Ответ 5

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

git stash show --patch | patch -p1

Ответ 6

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

Я не смог найти способ заставить git stash pop/apply заменить файлы, поэтому я сначала удаляю локальные копии неотслеживаемых файлов, которые были сохранены (будьте осторожны, так как это приведет к удалению любых изменений, которые не были зафиксированы) и примените скрытые изменения:

rm 'git ls-tree -r [email protected]{0}^3 --name-only'
git stash apply

Наконец, я использую git status, git diff и другие инструменты, чтобы проверять и добавлять обратно части из удаленных файлов, если чего-то не хватает.

Если у вас есть незафиксированные изменения, которые вы хотите сохранить, вы можете сначала создать временную фиксацию:

git add --all
git commit -m "dummy"
rm 'git ls-tree -r [email protected]{0}^3 --name-only'
git stash apply

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

git reset HEAD~1

Ответ 7

Моя аналогичная блокировка поп-операции состояла в том, что оставшиеся игнорировались файлы (см. файл .gitignore). Статус Git показал, что я отслеживал и не отслеживал, но мои действия не очищали проигнорированные файлы.

Детали: Я использовал git stash save -a, проверил мастер для компиляции и просмотра оригинального поведения, а затем попытался вернуть все, чтобы продолжить редактирование. Когда я проверил свою ветку и попытался попсу, мои проигнорированные файлы все еще были там до сохранения сохранения. Это связано с тем, что проверка хозяина затрагивала только зафиксированные файлы - он не уничтожал проигнорированные файлы. Таким образом, поп не удалось, по сути говоря, он не хотел восстанавливать мои скрытые игнорируемые файлы поверх файлов, которые все еще были там. К сожалению, я не мог понять, как начать слияние с ними.

В конечном итоге я использовал git clean -f -d -x для удаления игнорируемых файлов. Интересно, что из моих ~ 30, 4 файлов все еще осталось после очистки (похоронен в подкаталогах). Мне нужно выяснить, в какой категории они находятся, что их нужно вручную удалить.

Затем моя попка преуспела.

Ответ 8

Попробуйте это:

git checkout stash.

Ответ 9

Другое решение:

cd to/root/your/project

# Show what git will be remove
git clean -n

# If all is good
git clean -f

# If not all is good, see
git clean --help

# Finish
git stash pop

Ответ 10

С Git 2.14.x/2.15 (Q3 2017), qwertzguy от 2014 больше не потребуется.

До Q3 2017 вам пришлось удалить файл, о котором идет речь, а затем попытаться снова нажать pop/apply.
При следующем выпуске Git вам не придется этого делать.

См. commit bbffd87 (11 августа 2017 г.) Nicolas Morey -Chaisemartin (nmorey).
^{(слияние Junio ​​C Hamano - gitster - в совершить 0ca2f32, 23 августа 2017 г.}

stash: очистить незатребованные файлы до reset

При вызове git stash -u в репо, который содержит файл, который не является больше игнорируется из-за текущей модификации файла gitignoreэтот файл спрятан, но не удаляется из рабочего дерева.
Это связано с тем, что git-stash сначала выполняет reset --hard, который очищает .gitignore, а затем вызовите git clean, оставив файл нетронутым.
Это приводит к ошибке git stash pop из-за существующего файла.

Этот патч просто переключает порядок между очисткой и сбросом и добавляет тест для этой утилиты.

Ответ 11

Самый безопасный путь к следующему тиснению

git stash -u

Это будет сбрасывать все, включая неустановленное изменение

git отсечка

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