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
私は最初のハンクを適用するために「no」が続くスプリットで応答します。 2番目の塊、私は編集しようとします。私はもともと一番下の行を削除しようとしました-それは動作しませんでした。塊だけを完全に残しておくこともうまくいかず、その理由はわかりません。
この特定の例では、ハンクの行番号を微調整する必要があります。行を変更します。
@@ -1,6 +2,8 @@
そのため、代わりに次のようになります。
@@ -2,7 +2,8 @@
これは this git-add post のようなものですか？
ハンクを手動で編集することは非常に強力ですが、これまで行ったことがない場合は少し複雑です。
留意すべき最も重要なこと：diffは、他のインデントがある場合は常に1文字でインデントされます。
キャラクターは次のいずれかです。
- スペース（変更されていない行を示す）、
-行が削除されたことを示す、- または
+は、行が追加されたことを示します。他に何もありません。スペース、-、または+でなければなりません。それ以外の場合、エラーが発生します
（変更された行には文字がありません。古い行を削除し、変更された行を新しい行として追加することで処理されるためです）。お気に入りのテキストエディターで差分を開いているので（お気に入りのテキストエディターを使用するようにGitを構成しましたよね？）、結果の差分がきれいに適用されることを確認する限り、何でもできます。
そして、そこにトリックがあります。これを行ったことがない場合、Gitは「編集したハンクは適用されません。もう一度編集しますか？」と表示します。とても簡単に思えるかもしれませんが（または、Gitは何が欲しいのか分からないのでGit）、これを理解することができないために、頻繁に、あなたは自分自身を嫌い始めます。
よく私をつまずかせたのは、1文字のインデントを忘れたことです。
削除する行に-をマークしますが、ほとんどのテキストエディターでは-、以前のスペースは上書きされません。 これは、行全体にスペースを追加していることを意味します。これは、diffアルゴリズムが元のファイルの行を見つけることができない/一致しないことを意味し、Gitが叫ぶことを意味しますあなたで。もう1つは、差分がまだ意味をなさなければならないことです。 「センス」とは、きれいに適用できることを意味します。賢明な差分を正確に作成する方法は、少々暗いアートのように見えますが（少なくとも今のところ）、元のファイルがどのように見えるかを常に念頭に置いてから、それに応じて-sと+ sを計画する必要があります。十分な頻度でハンクを編集すると、最終的にはハングアップします。
こちらもご覧ください git add -pでコミット 。
Ortomala Lokni の answer はを参照します JoaquínWindmüllerブログ投稿「gitでコミットする変更を選択して選択します（または、Immaがハンクを編集します）」
Gitは行を数える代わりに、編集されたハンクを適用する前に、重複するハンクを編集します（編集された場合）。
それは 2018年半ばに議論された であり、次のようなシナリオを避けます：
ハンクを分割する場合、最初のサブハンクを編集し、末尾のコンテキスト行を削除に変換してから、2番目のサブハンクをステージングしようとすると失敗します。
もちろん、私はこれに遅れていますが、それにもかかわらず、この問題 昨年gitメーリングリストで議論された であり、それ以降はあまり変わっていないようだという記録について言及したかったのです。
この特定の問題は、同じハンクを編集しようとするandの分割に起因します。ジェフキングが最初に投稿した根本的な問題の分析は、基本的に次のとおりです。
ふむなるほど、分かりました。 「この差分を適用しますか？」チェックフィードboth git-applyへの分割パッチの一部。ただし、当然ながら、2番目の部分は正しく適用されません。そのコンテキストは最初の部分と重複していますが、考慮されていないためです。
justでチェックを行うと、編集されたパッチが機能します。ただし、分割パッチの残りの半分を受け入れるかどうかに応じて、編集したパッチが長期的に適用されない可能性があることは考慮されていません。そして、ユーザーが私たちに伝えなかったかもしれないので、まだそれを知ることができません（前半をスキップし、編集ステップの後、後で戻ってきたかもしれません）。
ジェフは、常に成功する非常に実用的な回避策で彼の投稿を締めくくります。
したがって、一般的に、同じ塊を分割して編集することは本質的に危険であり、この種の問題につながると思います。また、編集は機能のスーパーセットを提供するため、編集して、ハンクの最初の部分を適用できるようにするか、好みに応じないようにする必要があると思います。
以前に分割されていないハンクを編集することを選択するだけで、行番号を処理する必要がなくなります。
次のように、削除のためにステージングした行を削除しない場合
first line
-second line
third line
2行目を保持する場所で、必ず-は、行全体を削除するのではなく、スペースを追加します（追加された行を削除する場合）。 Gitはその行をコンテキストに使用します。
私は最近、このスレッドを読んで、手動編集を行う方法を見つけました。
私が使用したトリックは、このような差分がある場合です。
+ Line to add
+ Line to add
+ Line I dont want to include
+ Line I dont want to include
トリックは、このように見える差分を完全に作成したくない2行を削除することです。
+ Line to add
+ Line to add
これはほとんどの人にとって最も明白なことですが、今日まで私にとってはそうではなかったので、自分の経験を共有するだけだと思いました。この方法に危険があるかどうか教えてください。
ハンクヘッダーも正しく変更することが重要です（例：@@ -1,6 +1,9 @@）。 Joaquin Windmullerは、彼の ブログ投稿 の1つでハンクヘッダー編集の秘密を明らかにしています。
ハンクを編集する秘secret
ハンクを編集することは、最初は混乱する可能性があります。gitの指示は助けにはなりますが、始めるには十分ではありません。
# —|| # 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.秘密のソースは…行を数える：
- +で始まる行を削除した場合、1を新しい行カウント（ハンクのヘッダーの最後の桁）に引きます。
- -で始まる行を削除した場合、新しい行カウントに追加（ハンクのヘッダーの最後の桁）。
- 他の行（参照行）は削除しないでください。
これにより、ハンクをすばやく変更して、必要な部分を選択できるようになります。
私は同じ問題の解決策を探してこの質問に来ましたが、私の場合はgitを受け入れるためにハンクの行番号を変更する方法を理解できませんでした（上で提案したように）。しかし、git guiを使用して、これを実行するより良い方法を見つけました。そこで、diffでステージングする行を選択し、右クリックして「コミットからの行数」を選択します。 git-cola にも同じ機能があることを覚えています。
行番号を手動で編集できます。これは場合によっては間違いなく便利です。ただし、最初にハンクを分割しないことで、この特定の問題を回避できた可能性があります。
Gitが自動的に選択した後の部分を編集する必要があると思われる場合は、分割し、半分をステージングしてから残りの半分を編集するのではなく、ハンク全体を編集することをお勧めします。 Gitはそれを理解するのにより良い仕事をします。
このエラーが発生したときに発生した追加の問題は、編集ファイルを保存したときに行末が変更されたことです。
私はWindowsを使用し、編集にはメモ帳を使用していました（Windowsの行末でのみ保存します）。私のコードはNotepad ++で書かれており、Unix/Linuxスタイルの行末を持つように設定しました。
Notepad ++をデフォルトのgitエディターとして設定するように設定を変更したとき、ハンクを編集することができました。
git config --global core.editor "notepad++"
奇妙な「あなたの編集されたハンクが適用されない」メッセージ（「エラー：行にヘッダーのないパッチフラグメント...」のようなものが付随する可能性があります）の理由の1つは、末尾の空白を削除するように構成されているエディターの場合です。パッチは空の行をエンコードするため、空の行を含むハンクはそのようなエディターで保存すると適用に失敗するため、これは明らかに大きな問題を引き起こします。したがって、実際には、変更されていない空行を含むハンクは、末尾の空白の除去がオンの場合、編集後に適用に失敗します。
参考までに、上記の推奨手順に従ってパッチを追加すると、わずかに相互に関連するエラーが発生しました...ただし、エラーは表示されませんでした。同じハンクをステージングするように繰り返し求めてきました... Vim 7.4の古いバージョンを実行していることに気づきました... vimをアップグレードしましたが、期待どおりに動作しています。これが誰かの助けになることを願っています。