web-dev-qa-db-de.com

git add --interactive "Ihr bearbeiteter Hunk trifft nicht zu"

Ich versuche, git add --interactive zu verwenden, um selektiv einige Änderungen zu meinem Index hinzuzufügen, aber ich erhalte ständig die Meldung "Ihr bearbeitetes Stück ist nicht zutreffend. Erneut bearbeiten ..." Ich erhalte diese Nachricht auch, wenn ich die Option e wähle, und speichere/schließe sofort meinen Editor. Mit anderen Worten, ohne das Stück zu bearbeiten, wird der Patch nicht angewendet.

Hier ist das genaue Beispiel, das ich verwende (ich versuche, eine kleine Demo zusammenzustellen):

Originaldatei:

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

Neue Datei:

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

Ich versuche zu zeigen, wie man mit git add --interactive nur die "Bug Fix 1" -Zeile zum Index hinzufügt. Beim interaktiven Hinzufügen der Datei wähle ich den Patch-Modus. Es präsentiert mich mit 

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

Ich antworte mit Split, gefolgt von "Nein", um den ersten Hunk anzuwenden. Das zweite Stück versuche ich zu bearbeiten. Ich habe ursprünglich versucht, das Endergebnis zu löschen - das hat nicht funktioniert. Den Hunk komplett alleine zu lassen, funktioniert auch nicht und ich kann nicht verstehen, warum.

74
Josh

Für dieses spezielle Beispiel müssen Sie die Zeilennummern im Hunk optimieren. Ändern Sie die Zeile:

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

so dass es stattdessen liest:

 @@ -2,7 +2,8 @@ 
36
William Pursell

Ist das wie in dieser git-add post ?

Manuelles Bearbeiten des Hunks ist immens mächtig, aber auch ein bisschen kompliziert, wenn Sie es noch nie gemacht haben.
Das Wichtigste, das zu beachten ist: Der Diff wird immer mit einem Zeichen zusätzlich zu den anderen Einrückungen eingerückt.
Das Zeichen kann entweder sein:

  • ein Leerzeichen (zeigt eine unveränderte Linie an), 
  • ein -, der angibt, dass die Zeile entfernt wurde, 
  • oder ein +, der angibt, dass die Zeile hinzugefügt wurde. 

Nichts anderes. Es muss entweder ein Leerzeichen, ein - oder ein + sein. Alles andere, und Sie erhalten Fehler
(Es gibt kein Zeichen für eine geänderte Zeile, da diese durch Entfernen der alten Zeile und Hinzufügen der geänderten Zeile als neu behandelt werden).

Da Sie den Diff in Ihrem bevorzugten Texteditor geöffnet haben (Sie haben Git so konfiguriert, dass er Ihren bevorzugten Texteditor verwendet, oder?), Können Sie alles tun, was Sie möchten - solange Sie sicherstellen, dass der resultierende Unterschied korrekt ist.

Und darin liegt der Trick. Wenn Sie das noch nie gemacht haben, wird Git Ihnen sagen: "Ihr bearbeiteter Hunk trifft nicht zu. Nochmal bearbeiten?" so oft wirst du dich selbst hassen für deine Unfähigkeit, dies herauszufinden, obwohl es so einfach erscheint (oder Git, weil es nicht herausfinden kann, was du willst).

Eine Sache, die mich ziemlich stutzig machte, war, dass ich den Einzug des einen Zeichens vergessen habe.
Ich würde eine Zeile mit einem - markieren, um entfernt zu werden, aber in den meisten Texteditoren, die einen - einfügt, überschreibt sie nicht den Platz, der vorher vorhanden war. Dies bedeutet, dass Sie der gesamten Zeile ein zusätzliches Leerzeichen hinzufügen, was wiederum bedeutet, dass der Diff-Algorithmus die Zeile in der Originaldatei nicht finden/anpassen kann, was wiederum bedeutet, dass Git Sie anbrüllt.

Die andere Sache ist, dass der Unterschied noch einen Sinn ergeben muss. "Sense" bedeutet, dass es sauber angewendet werden kann. Genau wie Sie einen vernünftigen Diff erzeugen, scheint ein bisschen eine dunkle Kunst zu sein (zumindest für mich jetzt), aber Sie sollten immer daran denken, wie die Originaldatei aussah, und dann Ihre + und + entsprechend planen. Wenn du deine Kerle oft genug bearbeitest, wirst du den Dreh raus haben.

Siehe auch dieses commit auf git add -p .

94
VonC

Natürlich bin ich zu spät dran, wollte aber trotzdem erwähnen, dass diese Ausgabe wurde letztes Jahr auf der Git-Mailingliste diskutiert wurde und es scheint, als hätte sich seitdem nicht viel geändert.

Dieses spezielle Problem ist auf das Aufteilen von und zurückzuführen, die versuchen, das gleiche Hunk zu bearbeiten. Die von Jeff King ursprünglich veröffentlichte Analyse des zugrunde liegenden Problems lautet im Wesentlichen:

Hm. OK, ich verstehe. Die Checks "do this diff apply" prüfen beide Teile von das aufgeteilte Patch für git-apply. Aber natürlich wird der zweite Teil niemals richtig anwenden, da sich der Kontext mit dem ersten Teil überschneidet, jedoch berücksichtigt es nicht.

Die Prüfung mit nur des bearbeiteten Patches würde funktionieren. Aber das berücksichtigt nicht, dass der bearbeitete Patch möglicherweise fehlschlägt um sich langfristig zu bewerben, je nachdem, ob Sie die .__ akzeptieren oder nicht. andere Hälfte des Split-Patches. Und wir können das noch nicht wissen, weil die Der Benutzer hat uns möglicherweise nichts gesagt (er hätte die erste Hälfte überspringen können und dann später nach dem Bearbeitungsschritt darauf zurückkommen). 

Jeff schließt seinen Posten mit einem sehr pragmatischen Workaround ab, der immer erfolgreich ist und daher dringend empfohlen wird:

Im Allgemeinen denke ich, dass das Teilen und Bearbeiten desselben Blocks von Natur aus ___ ist. gefährlich und wird zu solchen Problemen führen. Und weil Die Bearbeitung bietet eine Obermenge der Funktionalität, ich denke, Sie sollten Bearbeiten Sie einfach und lassen Sie entweder den ersten Teil des Blocks anwenden oder nicht abhängig von Ihrer Präferenz. 

Wenn Sie nur einen Hunk bearbeiten, der zuvor nicht aufgeteilt wurde, müssen Sie sich nicht mit den Zeilennummern befassen.

40
Niels Ganser

Wenn Sie eine Zeile nicht löschen möchten, die zum Löschen bereitgestellt wurde, wie in

 first line
-second line
 third line

wenn Sie die zweite Zeile beibehalten möchten, stellen Sie sicher, dass Sie den - durch ein Leerzeichen ersetzen, anstatt die gesamte Zeile zu löschen (wie Sie eine hinzugefügte Zeile entfernen würden). Git verwendet die Zeile für den Kontext.

13
Rose Perrone

Ich habe kürzlich aus dem Lesen dieses Threads herausgefunden, wie man die manuelle Bearbeitung durchführt.

Der Trick, den ich benutzte, war der, wenn ich einen solchen Unterschied habe.

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

Der Trick besteht darin, die zwei Zeilen zu entfernen, die den resultierenden Diff nicht so aussehen lassen sollen.

+ Line to add
+ Line to add

Während dies für die meisten Menschen am offensichtlichsten ist, war es bis heute nicht für mich und ich dachte, ich sollte meine Erfahrungen nur teilen. Bitte sagen Sie mir, ob diese Methode gefährlich ist.

11
Sedrik

Es ist wichtig, auch den Blockheader korrekt zu ändern (z. B. @@ -1,6 +1,9 @@). Joaquin Windmuller enthüllt das Geheimnis der Bearbeitung von Kopfzeilen in einem seiner Blogpost .

Die Geheimnisse der Bearbeitung von Hunks

Das Bearbeiten der Hunks kann zunächst verwirrend sein. Die Anweisungen, die git Ihnen gibt, reichen jedoch nicht aus, um loszulegen.

# —||

# 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.

Die geheime Sauce ist… Linien zählen:

  • Wenn Sie eine Zeile entfernen, die mit + beginnt, dann subtrahieren Sie eine Zeile von der neuen Zeilenzahl (letzte Stelle der Kopfzeile des Hunks).
  • Wenn Sie eine Zeile entfernen, die mit - beginnt, dann fügen Sie eine zur neuen Zeilenzahl hinzu (letzte Ziffer der Kopfzeile des Hunks).
  • Entfernen Sie die anderen Linien (Referenzlinien) nicht.

Dies sollte es Ihnen ermöglichen, die Hunks schnell zu ändern, um die gewünschten Teile auszuwählen.

9
Ortomala Lokni

Ich kam zu dieser Frage und suchte nach einer Lösung für dasselbe Problem. Ich konnte nicht herausfinden, wie man die Zeilennummern (wie oben vorgeschlagen) im Hunk ändert, um in meinem Fall git zu akzeptieren. Ich habe einen viel besseren Weg gefunden, dies mit git gui zu tun. Dort können Sie die Zeilen im Diff auswählen, die Sie bereitstellen möchten, klicken Sie dann mit der rechten Maustaste und wählen Sie "Bühnenzeilen aus Commit". Ich erinnere mich, dass git-cola die gleiche Funktionalität hat.

6
Jayesh

Sie können die Zeilennummern manuell bearbeiten, was in manchen Fällen durchaus nützlich ist. Sie hätten dieses spezielle Problem jedoch wahrscheinlich vermeiden können, indem Sie den Hunk NICHT aufteilen. 

Wenn Sie sehen, dass Sie später wahrscheinlich etwas in dem von Git automatisch ausgewählten Hunk bearbeiten müssen, bearbeiten Sie am besten den gesamten Hunk, anstatt ihn zu teilen, die Hälfte zu inszenieren und die andere Hälfte zu bearbeiten. Git wird das besser herausfinden.

6
Michael Hines

Als ich diesen Fehler erhielt, bestand ein zusätzliches Problem darin, dass sich die Zeilenenden beim Speichern der Bearbeitungsdatei änderten.

Ich habe Windows und Notepad für meine Bearbeitungen verwendet (speichert nur mit Windows-Zeilenenden). Mein Code wurde mit Notepad ++ geschrieben und ich habe es so eingerichtet, dass es Zeilenende im Unix/Linux-Stil hat.

Als ich meine Einstellungen geändert habe, um Notepad ++ als Standard-Git-Editor zu verwenden, konnte ich meine Änderungen am Hunk vornehmen.

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

Ein Grund für die seltsamen Meldungen "Ihr bearbeitetes Stück gilt nicht" (möglicherweise begleitet von "error: patch fragment with header at line ...") könnte Ihr Editor sein, wenn er so konfiguriert ist, dass nachgestellte Leerzeichen entfernt werden. Dies würde offensichtlich zu großen Problemen führen, da Patches leere Zeilen codieren, da Zeilen mit einem Leerzeichen, das ein Hunk mit leeren Zeilen enthält, nicht zutreffen könnten, wenn er mit einem solchen Editor gespeichert wurde. In der Tat würde ein Hunk, der unveränderte Leerzeilen enthält, nach der Bearbeitung nicht angewendet werden, wenn der Strike-Whitespace aktiviert ist.

3
Timo

Zu Ihrer Information, ich habe einen leicht zusammenhängenden Fehler erhalten ... als ich nach dem oben angegebenen Vorschlag Patches hinzufügte ... Es zeigte jedoch keinen Fehler an. Ich bekam es immer wieder und bat mich, das gleiche Stück zu inszenieren ... Ich bemerkte, dass ich eine ältere Version von Vim 7.4 ausführte. Hoffentlich hilft das jemandem ..

0
Mantisimo