git add --interactive“편집 한 덩어리가 적용되지 않습니다.”

git add --interactive“편집 한 덩어리가 적용되지 않습니다.”

---

git add --interactive인덱스에 일부 변경 사항을 선택적으로 추가 하는 데 사용하려고하는데 "편집 한 덩어리가 적용되지 않습니다. 다시 편집 ..."메시지가 계속 나타납니다. e 옵션을 선택해도이 메시지가 표시되고 즉시 편집기를 저장 / 닫습니다. 즉, 덩어리를 전혀 편집하지 않으면 패치가 적용되지 않습니다.

다음은 내가 사용하는 정확한 예입니다 (작은 데모를 작성하려고합니다).

원본 파일 :

first change
second change off branch
third change off branch
second change
third change
fourth change

새로운 파일:

Change supporting feature 1
first change
second change off branch
third change off branch
second change
third change
fourth change
bug fix 1
change supporting feature 1

git add --interactive색인에 "버그 수정 1"줄만 추가 하는 데 사용하는 방법을 보여 주려고합니다 . 파일에서 대화 형 추가를 실행하고 패치 모드를 선택합니다. 그것은 나에게 선물한다

diff --git a/newfile b/newfile
index 6d501a3..8b81ae9 100644
--- a/newfile
+++ b/newfile
@@ -1,6 +1,9 @@
+Change supporting feature 1
 first change
 second change off branch
 third change off branch
 second change
 third change
 fourth change
+bug fix 1
+change supporting feature 1

나는 첫 번째 덩어리를 적용하기 위해 분할 후 "아니오"로 응답합니다. 두 번째 덩어리는 편집을 시도합니다. 나는 원래 결론을 삭제하려고 시도했지만 작동하지 않았습니다. 덩어리를 완전히 내버려 두는 것도 효과가 없으며 이유를 알 수 없습니다.

---

이 특정 예에서는 덩어리의 줄 번호를 조정해야합니다. 라인 변경 :

@@ -1,6 +2,8 @@

대신 다음과 같이 읽습니다.

@@ -2,7 +2,8 @@

---

이 git-add 게시물 과 비슷 합니까?

덩어리를 수동으로 편집하는 것은 매우 강력하지만 이전에 해본 적이 없다면 약간 복잡합니다.
명심해야 할 가장 중요한 사항 : diff는 다른 들여 쓰기에 추가하여 항상 한 문자로 들여 쓰기됩니다.
문자는 다음 중 하나 일 수 있습니다.

• 공백 (변경되지 않은 줄을 나타냄),
• -광고가 제거되었음을 나타내는,
• 또는 +라인이 추가되었음을 나타냅니다.

다른 건 없습니다. 공백,-또는 + 여야합니다. 다른 모든 것은 오류가 발생합니다
(변경된 줄에는 문자가 없습니다. 이전 줄을 제거하고 변경된 줄을 새 줄로 추가하여 처리하므로).

좋아하는 텍스트 편집기에서 diff를 열었으므로 (Git에서 좋아하는 텍스트 편집기를 사용하도록 구성 했습니까?) 원하는대로 할 수 있습니다. 결과 diff가 깔끔하게 적용되는지 확인하는 한 가능합니다.

그리고 거기에 속임수가 있습니다. 이전에이 작업을 한 적이 없다면 Git에서 "편집 한 덩어리가 적용되지 않습니다. 다시 편집 하시겠습니까?"라고 알려줍니다. 너무나 자주, 당신은 이것을 알아 내지 못하는 당신 자신을 증오하기 시작할 것입니다. 비록 그것이 너무 쉬워 보이지만 (또는 당신이 원하는 것을 알아낼 수 없기 때문에 Git).

나를 자주 넘어 뜨리는 한 가지는 내가 한 글자 들여 쓰기를 잊었다는 것입니다.
제거 할-로 줄을 표시하지만를 삽입하는 대부분의 텍스트 편집기 -에서는 이전에 있던 공백을 덮어 쓰지 않습니다. 이것은 전체 줄에 추가 공간을 추가한다는 것을 의미합니다. 즉, diff 알고리즘이 원본 파일에서 줄을 찾거나 일치시킬 수 없다는 것을 의미합니다 . 즉, Git이 당신에게 소리를지를 것임을 의미합니다 .

다른 한 가지는 diff가 여전히 의미가 있어야한다는 것입니다. "센스"는 깔끔하게 바를 수 있다는 뜻입니다. 당신이 현명한 diff를 생성하는 정확한 방법은 (적어도 지금 당장 나에게는) 약간 어두운 예술처럼 보이지만, 당신은 항상 원본 파일이 어떻게 생겼는지 염두에두고 그에 따라 -s와 + s를 계획해야합니다. 심술쟁이를 충분히 자주 편집하면 결국 익숙해 질 것입니다.

git add -p에 대한 이 커밋 도 참조하십시오 .

Ortomala Lokni 의 답변 은 Joaquín Windmüller 블로그 게시물 " git로 커밋 할 변경 사항 선택 (또는 Imma 편집 당신의 덩어리) "

줄을 세는 대신 Git이 원하는 것은 편집 된 덩어리를 적용하기 전에 겹치는 덩어리를 합치는 것입니다 (편집 될 때).
이는 2018 년 중반 에 논의 되었으며 다음과 같은 시나리오를 피할 것입니다.

덩어리를 분할하는 경우 첫 번째 하위 덩크를 편집하고 후행 컨텍스트 줄을 삭제로 변환 한 다음 두 번째 하위 덩크를 준비하려고하면 실패합니다.

---

물론 나는 이것에 늦었지만 그럼에도 불구하고이 문제 는 작년에 git 메일 링리스트에서 논의 되었고 그 이후로 많이 변하지 않은 것 같다는 기록을 위해 언급하고 싶었 습니다.

이 특정 문제 는 동일한 덩어리를 분할 하고 편집하려는 시도 에서 비롯됩니다 . 원래 Jeff King이 게시 한 기본 문제에 대한 분석은 다음과 같습니다.

Hm. OK, I see. The "does this diff apply" check feeds both parts of the split patch to git-apply. But of course the second part will never correctly apply, because its context overlaps with the first part, but doesn't take it into account.

Doing the check with just the edited patch would work. But that doesn't take into account that your edited patch will potentially fail to apply in the long run, depending on whether or not you accept the other half of the split patch. And we can't know that yet, because the user may not have told us (they could have skipped the first half, and then come back to it later after the edit step).

Jeff concludes his post with a very pragmatic workaround that always succeeds, and is thus highly recommended:

So in general, I think splitting and editing the same hunk is inherently dangerous and is going to lead to these sorts of problems. And because editing provides a superset of the functionality, I think you should just edit and either allow the first part of the hunk to be applied or not depending on your preference.

By only choosing to edit a hunk not previously split, you will not have to deal with the line numbers.

---

When you want to not delete a line that staged for deletion, as in

 first line
-second line
 third line

where you want to keep the second line, make sure you replace the - with a space, rather than deleting the whole line (as you would to get rid of an added line). Git will use the line for context.

---

It's important to also correctly modify the hunk header (e.g. @@ -1,6 +1,9 @@). Joaquin Windmuller reveal the secret of hunk header editing in one of his blog post.

The secrets of editing hunks

Editing the hunks can be confusing at first, the instructions that git gives you help but are not enough to get started.

# —||

# To remove ‘-’ lines, make them ’ ’ lines (context).

# To remove ‘+’ lines, delete them.

# Lines starting with # will be removed.

#

# If the patch applies cleanly, the edited hunk will immediately be

# marked for staging. If it does not apply cleanly, you will be given

# an opportunity to edit again. If all lines of the hunk are removed,

# then the edit is aborted and the hunk is left unchanged.

The secret sauce is…counting lines:

• If you remove a line that starts with + then subtract one to the new line count (last digit of the hunk’s header).
• If you remove a line that starts with - then add one to the new line count (last digit of the hunk’s header).
• Don’t remove the other lines (reference lines).

This should allow you to quickly modify the hunks to select the parts you want.

---

I recently figured out from reading this thread how to work the manual editing.

The trick I used was that if I have a diff like this.

+ Line to add
+ Line to add
+ Line I dont want to include
+ Line I dont want to include

The trick is to remove the two line I do not want completely making the resulting diff looking like this.

+ Line to add
+ Line to add

While this is most likley obvious to most people it was not for me until today and I thought I should just share my experience. Please tell me if there is any danger to this method.

---

You can manually edit the line numbers, that's definitely useful in some cases. However, you probably could have avoided this particular problem by NOT first splitting the hunk.

If you see that you'll probably need to edit something later in the hunk that Git has automatically chosen, it's best to just edit the whole hunk rather than splitting, staging half, and then editing the other half. Git will do a better job figuring that out.

---

I came to this question looking for solution to same problem, and couldn't figure out how to change the line numbers (as suggested above) in the hunk to get git accept it in my case. I found a much better way to do that using git gui though. There you can select the lines in the diff that you want to stage, then right click and choose "Stage lines from commit". I remember git-cola has the same functionality too.

---

An additional problem I had when I got this error was that the line endings changed when I saved the edit file.

I was using Windows and using Notepad for my edits (only saves with Windows line-endings). My code was written with Notepad++ and I set it up to have Unix/Linux style line endings.

When I changed my settings to have Notepad++ as the default git editor I was able to make my edits to the hunk.

git config --global core.editor "notepad++"

---

One reason for weird "Your edited hunk does not apply" messages (likely accompanied with something like "error: patch fragment without header at line...") might be your editor if it's configured to strip trailing whitespace. This would obviously cause major problems as patches encode empty lines as lines with one space any hunk containing empty lines would fail to apply if saved with such an editor. So in effect any hunk containing any unchanged empty lines would fail to apply after editing with if stripping trailing whitespace is on.

---

FYI, I was getting a slightly interrelated error... when I add patched following the suggested instruction above... It was showing no error, however. I was getting it repeatedly asking me to stage the same hunk... I noticed I was running an older version of Vim 7.4... I upgraded vim and it's working as expected now. Hopefully this will help someone..

참고URL : https://stackoverflow.com/questions/3268596/git-add-interactive-your-edited-hunk-does-not-apply