#git #git-stash
#мерзавец #мерзавец-заначка
Вопрос:
Такое поведение больше похоже на ошибку для меня, но, возможно, я что-то упускаю.
Во-первых, вот что я сделал:
0) `mkdir mytest amp;amp; cd mytest` 1) `git init`: Created an empty git repo 2) `echo "test" gt;test.txt amp;amp; git commit -a -m "init"`: Created 1 commit with a single file 3) `echo "test2" gt;test.txt amp;amp; echo "test2" gt;test2.txt`: Made some changes in the file i committed created a new file 4) `git stash -u`: Used stash -u to save my changes 5) `echo "test3" gt;test.txt amp;amp; git commit -a -m "2"`: Created a second commit with a different change on the existing file in order to force a conflict 6) `git stash pop`: I git stash pop to create a conflict between the second commit and my stash from my first commit
Я ожидал, что у меня будет 1 файл в стадии конфликта и неотслеживаемый файл, который будет создан в моем текущем рабочем каталоге, но при запуске git status
я смог найти только конфликт:
mytest git:(master) ✗ git status On branch master Unmerged paths: (use "git restore --staged lt;filegt;..." to unstage) (use "git add lt;filegt;..." to mark resolution) both modified: test.txt
Является ли это ожидаемым поведением? Как я могу разрешить конфликт и вернуть мой неотслеживаемый файл?
Комментарии:
1.Я советую избегать
git stash
этого. В команде исторически было множество ошибок, и это, похоже, еще одна. Он делает то, что не следует делать (делает коммиты, которые вы не можете найти или использовать каким-либо обычным способом), таким способом, который трудно использовать.
Ответ №1:
Если конфликт разрешится в том или ином случае, вы в порядке, вы можете просто разрешить его git stash pop
снова, чтобы вернуть неотслеженные файлы, но если какой-либо элемент разрешения не идентичен ни одному из родителей, вам придется сделать это вручную: разрешить конфликты слияния, затем
# after resolving conflicts index=`git write-tree` git read-tree -u --prefix= stash^3 git read-tree $index
Нет, это не должно быть нормально.
Ответ №2:
Обратите внимание, что технически то, что хранится в тайнике, является фиксацией (точнее, фиксацией слияния).
Вы можете просмотреть это, запустив :
git log --oneline --graph stash
Часть с неотслеживаемыми файлами (при запуске git stash -u
) является 3-м родителем stash
фиксации : stash^3
Если вы находитесь в ситуации, когда использование git stash apply
или git stash pop
не работает, поскольку при восстановлении отслеживаемой части файлов возникают конфликты, вы можете :
- исправьте проблемы с этой первой частью (например, исправьте конфликты
test.txt
)., - используйте другие команды git для перечисления или извлечения файлов из части «неотслеживаемые файлы» тайника :
git show --name-only stash^3 git checkout stash^3 -- that/file # warning : will overwrite the content of # 'that/file' if you have a local one # if you have a clean index : git checkout stash^3 -- . git reset HEAD # etc ...
Комментарии:
1. Ситуация OP проявляется только тогда, когда есть конфликты, которые не разрешаются ни тем, ни другим, и сброс отменит поэтапные разрешения.
2. @jthill : вы правы, я думал о запуске этих команд в чистом индексе. Надеюсь, мой обновленный ответ будет более ясным.