때때로`git stash -p`가 실패하는 이유는 무엇입니까?

때때로`git stash -p`가 실패하는 이유는 무엇입니까?

---

나는 ♥ git stash -p. 하지만 가끔은,의 만족 세션 후 y, n그리고 s,이 얻을 :

Saved working directory and index state WIP on foo: 9794c1a lorum ipsum
error: patch failed: spec/models/thing_spec.rb:65
error: spec/models/thing_spec.rb: patch does not apply
Cannot remove worktree changes

왜?

---

git stash -pGit 2.17 (2018 년 2 분기)에서는 실패가 줄어들 것입니다.
그 전에는 " git add -p"(와 논리를 공유 함 git stash)은 결과를 기본 " git apply"에 전달하기 전에 분할 패치를 통합하는 데 게으 르기 때문에 코너 케이스 버그가 발생했습니다. 덩어리 선택이 강화 된 후에 적용될 패치를 준비하는 로직.

참조 3a8522f 커밋 , b3e0fcf 커밋 , 2b8ea7f 커밋 , (05 3 월 2018) fecc6f3 커밋 , 23fea4c 커밋 , 902f414 커밋 (2018 3월 1일), 및 11489a6 커밋 , e4d671c 커밋 , 492e60c을 투입 하여 (2018년 2월 19일) 필립 우드 ( phillipwood) .
^{(Merged by Junio ​​C gitsterHamano -- in commit 436d18f , 14 Mar 2018)}

add -p: 하나를 건너 뛸 때 후속 덩어리의 오프셋을 조정합니다.

(추가하지만 다시 숨김에 적용될 수 있음)

8cbd431 커밋 이후 ( " git-add--interactive: replace hunk recounting with apply --recount", 2008-7-2, Git v1.6.0-rc0) 덩어리를 건너 뛰면 컨텍스트 줄에 의존하여 올바른 위치에 후속 덩어리를 적용합니다.

이것은 대부분의 경우 작동하지만 덩어리가 잘못된 위치에 적용될 수 있습니다.

이 문제를 해결하려면 다음 덩어리의 오프셋을 조정하여 건너 뛴 덩어리로 인한 삽입 또는 삭제 수의 변경을 수정합니다. 삽입 또는 삭제 횟수가 변경된 편집 된 덩어리로 인한 오프셋 변경은 여기에서 무시되며 다음 커밋에서 수정됩니다.

여기에서 몇 가지 테스트 를 볼 수 있습니다 .

---

Git 2.19가 향상되었습니다 git add -p. 사용자가 " git add -p" 에서 패치를 편집하고 사용자 편집기가 후행 공백을 무차별 적으로 제거하도록 설정하면 패치에서 변경되지 않은 빈 줄이 완전히 비어있게됩니다 (단일 SP가있는 줄 대신).
Git 2.17 타임 프레임에 도입 된 코드는 이러한 패치를 파싱하지 못했지만 이제 상황을 파악하고 대처하는 법을 배웠습니다.

Phillip Wood ( )의 commit f4d35a6 (2018 년 6 월 11 일)을 참조하십시오 . ^{(Merged by Junio ​​C Hamano -- in commit 5eb8da8 , 28 Jun 2018)}phillipwood
gitster

add -p: 편집 된 패치에서 빈 컨텍스트 줄 계산 수정

recount_edited_hunk()에 도입 2b8ea7f 커밋 ( "-p 추가 계산 오프셋 델타을 편집 패치", 2018년 3월 5일, 힘내 v2.17.0)을 공백으로 시작하는 모든 상황에 맞는 라인을 요구, 빈 줄은 계산되지 않습니다.
이것은 사용자가 패치를 편집 할 때 마지막에 빈 줄을 도입 한 경우 재 계산 문제를 방지하기위한 것입니다.

그러나 이것은 git add -p패치를 편집 할 때 편집자가 빈 컨텍스트 줄에서 후행 공백을 제거하여 계산해야하는 빈 줄을 도입하는 것이 일반적인 것처럼 보이기 때문에 ' '로 회귀를 도입했습니다 .
'git apply'는 이러한 빈 줄을 처리하는 방법을 알고 있으며 POSIX는 빈 컨텍스트 줄에 공백이 있는지 여부가 구현 정의되어 있다고 말합니다 ( diff 명령 참조 ).

줄 바꿈으로 만 구성된 줄과 공백으로 시작하는 줄을 컨텍스트 줄로 계산하여 회귀를 수정하고 향후 회귀를 방지하는 테스트를 추가합니다.

---

Git 2.23 (2019 년 3 분기)은 패치를 선택적으로 적용해야하는 git add -p" git checkout -p" 에서 사용 하는를 개선 했습니다. 이전에는 제대로 작동하지 않았습니다.

Phillip Wood ( )의 commit 2bd69b9 (2019 년 6 월 12 일)를 참조하십시오 . ^{(의해 병합 - Junio C 하마노 - 에 1b074e1 커밋 2,019 09 날짜 : Jul)}phillipwood
gitster

add -p: checkout -p병리학 적 맥락으로 수정

Commit fecc6f3 ( " add -p: 하나를 건너 뛸 때 후속 덩어리의 오프셋 조정", 2018-03-01, Git v2.17.0-rc0) 이전 덩어리를 건너 뛰었을 때 올바른 위치에 덩어리를 추가하는 문제를 수정했습니다.

그러나 반대로 적용되는 패치는 다루지 않았습니다.

이 경우 패치를 적용 할 때 사후 이미지 오프셋이 올바르게 조정되도록 사전 이미지 오프셋을 조정해야합니다.
패치가 반전 될 때 델타를 더하기보다는 빼기 (이에 대해 생각하는 가장 쉬운 방법은 건너 뛴 삭제 덩어리를 고려하는 것입니다.이 경우 오프셋을 줄여서 빼야합니다).

---

이것은 내가 덩어리를 너무 가까운 작은 덩어리로 나누려고 할 때마다 발생합니다 (변경 사항 사이에 3 줄 미만). 짧은 설명은 패치에 로컬 변경 사항과 충돌하는 컨텍스트 라인이 있다는 것입니다. 아래에 더 자세한 설명이 있습니다.

---

커밋되지 않은 변경 사항이있는 git repo가 ​​있다고 가정합니다.

--- a/pangram
+++ b/pangram
@@ -1,8 +1,8 @@
 The
-quick
+relatively quick
 brown
 fox
-jumps
+walks
 over
 the
 lazy

첫 번째 변경 사항을 숨기면 다음을 얻습니다.

--- a/pangram
+++ b/pangram
@@ -1,5 +1,5 @@
 The
-quick
+relatively quick
 brown
 fox
 jumps

이 git stash명령은 실제로 패치 (check git stash list) 를 저장하는 데 성공 하지만 git은 해당 패치를 반대로 사용하여 내 작업 디렉토리에서 숨겨진 변경 사항을 제거합니다. 덩어리 이후의 컨텍스트에는 "점프"가 있는데, 이는 여전히 내 작업 디렉토리에있는 "걷기"와 일치하지 않습니다. 그래서 자식은

오류 : 패치 실패 : pangram : 1
오류 : 판 그램 : 패치가 적용되지 않습니다
작업 트리 변경 사항을 제거 할 수 없습니다.

and leaves all the changes in my working dir, and the stash becomes pretty much worthless.

---

I would call this a bug in git's hunk splitting support. If it knows it's splitting the changes too close, it could shave off a few lines of context from the patch, or jimmy the patch to have the modified context lines instead of the pristine ones. Alternatively, if splitting hunks this close is officially unsupported, it should actually refuse to split hunks that close.

---

After just having a git stash -p fail in this same way, I had luck with this workaround (git 2.0.2):

• git add -p, splitting the exact same hunks but with inverse answers ("y" to add "keeps" changes, "n" to stash keeps changes.)
• git stash -k to keep the index and stash everything else
• git reset to continue working on my files

I'm not sure why git add -p didn't fail in the same way that git stash -p did. I guess because adding works with the index rather than creating a patch file?

---

The accepted answer at the moment can still unfortunately fail, even in Git 2.17.

If, like me, you spent a lot of effort constructing the perfect stash and don't want to throw that effort away, it is still possible to mostly get what you want with:

git stash show -p | patch -p1 -R

This will fail with rejects, but odds are good most of the hunks will apply correctly and at least save you the time of reviewing all the files again.

---

Applying the state can fail with conflicts; in this case, it is not removed from the stash list. You need to resolve the conflicts by hand and call git stash drop manually afterwards

참고URL : https://stackoverflow.com/questions/5047366/why-does-git-stash-p-sometimes-fail