2013-02-01 6 views
24

Ich versuche gerade, die PRs eines (github) repositorys code-style zu überprüfen, und ich möchte Patches an die Übergeber liefern, mit denen sie den Codestyle einfach beheben können. Zu diesem Zweck ziehe ich ihre PR herunter, führe unser Uncrustify-Skript darüber, um alle Stilfehler zu beheben, und möchte eine .patch-Datei erstellen, die sie leicht anwenden können. Es bricht jedoch einige Dateien ständig ab.git-apply schlägt auf mysteriöse Weise fehl, wie behebe ich Fehler?

ich tun (git Version 1.7.10.4 mit core.autocrlf=input, core.filemode=false):

$ git checkout pr-branch 
$ git log -1 (shows: commit dbb8d3f) 
$ git status (nothing to commit, working directory clean) 
$ <run the code styler script, which modifies some files> 
$ git diff > ../style.patch (so the patch file lands outside the repo) 
$ git reset --hard HEAD (to simulate the situation at the submitter's end) 
$ git log -1 (shows: commit dbb8d3f) 
$ git status (nothing to commit, working directory clean, so we are where we started) 
$ git apply ../style.patch 
error: patch failed: somefile.cpp:195 
error: somefile.cpp: patch does not apply (same output using the --check option) 

Dies gilt nur für einige Dateien, nicht alle von ihnen. Ich weiß nicht, wie ich das Problem beheben soll, d. H. Wie bekomme ich git, mir genau zu sagen, wo es schief geht - es sagt mir nur ein Stück #, wenn ich graben, aber das ist immer noch ziemlich groß.

Was ich bisher versucht (ohne Erfolg):

  1. apply --reverse, apply --whitespace=nowarn
  2. diff HEAD statt diff allein
  3. eine Dummy machen begehen (! Arbeiten ohne Probleme zu begehen), verwenden format-patch , löschen Sie das Dummy-Commit, wenden Sie das Patch mit git-am mit oder ohne -3 an, oder wenden Sie sich an git-apply
  4. Haben Sie die Patch-Datei in der lo cal dir statt einem nach oben (dem Strohhalm greifen, hier)
  5. den man-pages von git-diff überprüfen, -Tragen, nützliches -format-Patch, -am für alles
  6. Patch mit dem Linux patch Befehl
  7. ....

Ich weiß nicht, was mit dem Diff falsch sein könnte. Whitespace-Dinge sollten nur warnen, oder? In jedem Fall werde ich sie nicht ignorieren wollen, da es sich um eine Stilfixierung handelt, die offensichtlich Leerzeichen beinhaltet.

Wie kann ich das reparieren/diagnostizieren oder sogar herausfinden, wo es genau funktioniert? Würde es helfen, wenn ich den Diff einer der Täterdateien gepostet hätte? Was mich auch verblüfft ist, dass das Commit ohne Probleme funktioniert, aber das Patch vom Commit nicht erstellt wird ??

Nachdem mit diesem Ring für mehrere Stunden, die ich am Ende meines Wissens bin ...

+5

'git gelten - "Ablehnen", um die abgelehnten Änderungen zu sehen. – aragaer

+0

Versuchte das schon ... das zeigt nur das ganze Stück, das scheitert (ungefähr 2-300 Zeilen in diesem einen Fall), also nicht sehr informativ – Christoph

+0

Eine andere Vermutung - es könnte einige Umbenennungen geben und etwas könnte "gitimorned" werden als Ergebnis. – aragaer

Antwort

23

Update:

Sie git apply -v können detailliertere Informationen über sehen, was los ist, git apply --check um die Operation zu überprüfen, oder git apply --index, um die lokale Indexdatei neu zu erstellen.

Basierend auf Ihrem Kommentar, es scheint, dass Ihr lokaler Index beschädigt wurde, und so index löste es.

Ich werde meine ursprüngliche Antwort und die Kommentare meist verlassen, um den Leuten Kontext zu geben, was vor sich ging, da ich vermute, dass andere Leute zu denselben anfänglichen Schlussfolgerungen springen würden, die ich auf der Problembeschreibung basiert hatte.

------

Wahrscheinlich ist nichts mit dem diff falsch.Sehen Sie sich stattdessen das Ziel-Git-Repository an. Während Sie dabei sind git reset --hard HEAD, nichts garantiert Ihnen, dass die HEAD auf diesem anderen Repository ist die gleiche wie die HEAD auf Ihrem.

Do git log auf dem Ziel Repo und schauen Sie sich das Commit an der Spitze. Ist es das gleiche wie das, aus dem du das Diff herstellst? Höchstwahrscheinlich ist es nicht. Schauen Sie sich den Verlauf an und prüfen Sie, ob die von Ihnen benötigte Überweisung vorhanden ist. Wenn dies der Fall ist, ist das Ziel-Repo vor Ihnen, und Sie müssen zurückgehen, machen Sie git pull (oder git rebase) und produzieren Sie ein neues Diff. Ist dies nicht der Fall, liegt das Ziel-Repo hinter Ihrem, und Sie müssen git pull (oder git rebase) auf dem Ziel-Repo ausführen, um es auf den neuesten Stand zu bringen.

Denken Sie daran, dass Sie, wenn Sie andere Leute zu Ihrem "Master" -Repo verpflichten (der, wo Bot Ihre und die Ziel-Repositories ziehen), müssen Sie git pull beide Repositories, um sie zu einem relativ aktuellen zu bekommen gemeinsames Commit.

+0

In der Prozedur, die ich oben beschrieben habe, ist der aktuelle HEAD derselbe für Diff-Erstellung und Diff-Anwendung. Es ist das letzte Commit in diesem Zweig. Ich mache den Reset genau, um Probleme von verschiedenen HEADs zu eliminieren. das kann es nicht sein. Aktualisierung bei Bedarf wird bereits automatisch durchgeführt, aber wenn die Anwendung in der obigen Testsituation nicht funktioniert, wird sie auch dort fehlschlagen, so dass dies vorher gelöst werden muss. – Christoph

+0

Es ist nicht klar aus Ihrer Beschreibung, wenn beide HEADs auf denselben Commit zeigen. Meine Vermutung ist, dass sie nicht sind, aber wenn Sie sie überprüft haben und sie sind, dann stimmt tatsächlich etwas mit dem Unterschied. –

+0

Probieren Sie auch 'git apply -v' aus oder spielen Sie mit den Optionen' --check' und '-index'. –

3

versuchen gegen Ihre Patch-Datei zu überprüfen - Beispiel:

git apply --reject mypatch.patch 

dies Sie Unterschiede zeigen, wenn überhaupt - hier ist ein Beispiel dafür, wie es aussehen könnte:

error: patch failed: <filename>:<linenumber> 
error: while searching for : 
    cout << "}" << endl; // example of a line in your patch 
+0

Es sieht dort aus, aber es gibt immer noch diesen Fehler –

Verwandte Themen