Всплывающее окно Git stash с неотслеживаемыми файлами не распаковывается без отслеживания, если возникает конфликт?

#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 : вы правы, я думал о запуске этих команд в чистом индексе. Надеюсь, мой обновленный ответ будет более ясным.