Чому git stash pop каже, що він не міг відновити невідстежені файли зі сховища?

У мене була купа інсценізованих та нестадійних змін, і я хотів швидко перейти до іншої гілки, а потім повернутися назад.

Тож я влаштував свої зміни за допомогою:

$ git stash push -a

(Оглянувшись назад, я, мабуть, міг би використовувати --include-untrackedзамість цього --all)

Потім, коли я пішов виводити схованку, я отримую безліч помилок, подібних до:

$ git stash pop
foo.txt already exists, no checkout
bar.txt already exists, no checkout
...
Could not restore untracked files from stash entry

Здається, що ніяких змін, відновлених із схованки, не було.

Я також намагався, $ git stash branch tempале це показує ті самі помилки.

Я все-таки придумав спосіб обійти це, яке було використовувати:

$ git stash show -p | git apply

Наразі катастрофу запобігають, але це викликає деякі питання.

Чому ця помилка сталася спочатку і як мені уникнути її наступного разу?

Як трохи додаткового пояснення зверніть увагу, що git stashробиться або два коміти, або три коміти. За замовчуванням два; Ви отримуєте три, якщо використовуєте будь-яке написання параметрів --allабо --include-untracked.

Ці два, або три, коміти є особливими одним важливим чином: вони не знаходяться в жодному відділенні. Git знаходить їх за спеціальною назвою stash. ¹ Найголовніше, однак, це те, що Git дозволяє вам - і змушує - робити ці два-три коміти. Щоб зрозуміти це, нам потрібно подивитися, що в цих комітах.

Що всередині схованки

У кожному коміті може бути перелік одного або декількох батьківських комітів. Вони утворюють графік, де пізніше коміти вказують на попередні. Зазвичай сховище містить два коміти, які я люблю називати iдля вмісту індексу / області прогону та wдля вмісту робочого дерева. Пам'ятайте також, що кожен коміт містить знімок. У звичайному коміті цей знімок зроблений із вмісту індексу / області прогону. Тож iкоміт насправді є цілком нормальним комітом! Це просто не на жодній гілці:

...--o--o--o   <-- branch (HEAD)
           |
           i

Якщо ви робите звичайний тайник, git stashкод робить wзараз, копіюючи всі ваші відстежувані файли робочого дерева (у тимчасовий допоміжний індекс). Git встановлює першого з батьків цього wкоміту вказувати на HEADкоміт, а другого з батьків - на фіксацію i. Нарешті, він встановлює stashвказівку на цей wкоміт:

...--o--o--o   <-- branch (HEAD)
           |\
           i-w   <-- stash

Якщо ви додаєте --include-untrackedабо --all, Git робить додатковий коміт, uміж перервами iта w. Вміст знімка для - uце ті файли, які не відстежуються, але не ігноруються ( --include-untracked), або файли, які не відслідковуються, навіть якщо вони ігноруються ( --all). Це додаткове uзобов'язання не мають ні батьків, а потім , коли git stashмарка w, вона встановлює w«s третього батька це uзробити, так що ви отримаєте:

...--o--o--o   <-- branch (HEAD)
           |\
           i-w   <-- stash
            /
           u

На цьому етапі Git також видаляє будь-які файли робочого дерева, які заводились у uкоміті (використовуючи git cleanдля цього).

Відновлення схованки

Коли ви хочете відновити схованку, у вас є можливість використовувати її --indexабо не використовувати. Це говорить git stash apply(або який - або з команд , які внутрішньо використовувати apply, наприклад pop) , що він повинен використовуватиi зробити , щоб спробувати змінити свій поточний індекс. Ця модифікація виконується за допомогою:

git diff <hash-of-i> <hash-of-i's-parent> | git apply --index

(більш-менш; тут є купа дрібних деталей, які заважають цій основній ідеї).

Якщо ви пропустите --index, git stash applyповністю ігнорує iкоміт.

Якщо схованка має лише два коміти, git stash applyтепер можна застосувати wкоміт. Він робить це, викликаючи git merge² (не дозволяючи йому фіксувати або розглядати результат як звичайне злиття), використовуючи вихідний коміт, для якого було зроблено сховище ( iбатьківський та wперший батьківський) як основу злиття, wяк --theirscommit, а ваш поточний (HEAD) коміт як ціль злиття. Якщо злиття вдається, все добре - ну, принаймні Git так думає - і git stash applyсамо успіх. Якщо раніше ви git stash popзастосовували схованку, код тепер скидає схованку. ³ Якщо злиття не вдається, Git оголошує заявку невдалою. Якщо ви використовувалиgit stash pop, код зберігає схованку і надає той самий статус відмови, що і для git stash apply.

Але якщо у вас є третій коміт - якщо uу сховищі, яке ви застосовуєте, є коміт - тоді все змінюється! Немає можливості робити вигляд, що uкоміт не існує. ⁴ Git наполягає на вилученні всіх файлів із цього uкоміту в поточне дерево роботи. Це означає, що файли або не повинні взагалі існувати, або мати такий самий вміст, як у uкоміті.

Щоб це сталося, ви можете скористатися git cleanсобою, але пам’ятайте, що файли, що не відстежуються (ігноруються чи ні), не існують у сховищі Git, тому будьте впевнені, що ці файли можуть бути знищені! Або ви можете створити тимчасовий каталог і перенести туди файли на зберігання - або навіть зробити інший git stash save -uабо git stash save -a, оскільки вони працюватимуть git cleanза вас. Але це просто залишає у вас інший uзапас у стилі, з яким слід мати справу пізніше.

¹ Це насправді refs/stash. Це має значення, якщо ви робите філію з іменем stash: повне ім’я філії refs/heads/stash, тому вони не суперечать. Але не робіть цього: Git не заперечить, але ви заплутаєте себе. :-)

²git stash код на насправді використовує git merge-recursiveпрямо тут. Це необхідно з багатьох причин, а також має побічним ефектом переконання, що Git не розглядає це як злиття, коли ви вирішуєте конфлікти та фіксуєте.

³ Ось чому я рекомендую уникати git stash popна користь git stash apply. Ви отримуєте шанс розглянути то , що отримав застосовані, і вирішити , чи був він на самому справі застосовується правильно. Якщо ні, у вас все ще є схованка, це означає, що ви можете використати, git stash branchщоб відновити все ідеально. Ну, якщо припустити відсутність цього докучливого uкоміту.

⁴ Справді повинно бути: git stash apply --skip-untrackedабо щось інше. Також повинен бути варіант, який означає викинути всі ці uфайли комітів до нового каталогу , наприклад git stash apply --untracked-into <dir>, можливо.

Мені вдалося відтворити вашу проблему. Здається, якщо ви зберігаєте невідстежені файли, а потім створюєте ці файли (у вашому прикладі foo.txtта bar.txt), то у вас відмічаються локальні зміни до відстежених файлів, які будуть перезаписані під час застосування git stash pop.

Щоб обійти цю проблему, ви можете використати таку команду. Це замінить будь-які незбережені локальні зміни, тому будьте обережні.

git checkout stash -- .

Ось додаткова інформація, яку я знайшов у попередній команді .

Щоб розширити відповідь Даніеля Сміта : цей код відновлює лише відстежувані файли, навіть якщо ви використовували --include-untracked(або -u) під час створення схованки. Повний код:

git checkout stash -- .
git checkout stash^3 -- .
git stash drop

# Optional to unstage the changes (auto-staged by default).
git reset

Це повністю відновлює відстежуваний вміст (in stash) та невідстежений вміст (in stash^3), а потім видаляє схованку. Кілька приміток:

• Будьте обережні - це перезапише все вашим схованним вмістом!
• Відновлення файлів із автоматично git checkoutпризводить до того, що всі git resetвони стартують автоматично, тому я додав, щоб все зняти.
• Деякі ресурси використовують, stash@{0}і stash@{0}^3під час мого тестування він працює однаково з або без@{0}

Джерела:

• Примусити git stash перезаписувати додані файли (посилання у відповіді Даніеля Сміта)
• Як я можу перевірити невідстежений файл у скриньці git? (інформація про магічну stash^3комісію)
• Посібник Atlassian по git stash (перегляньте "Як працює git stash", щоб дізнатися більше про внутрішні коміти)

крім інших відповідей, я зробив невеличку хитрість

• Видалено всі нові файли (вже існуючі файли, наприклад у запитанні foo.txt та bar.txt)
• git stash apply (можна використовувати будь-яку команду, наприклад, застосувати, поп тощо)