Java-fähiger Zusammenführungsbefehl

Jedes Mal, wenn ich in meinem SCM einen Konflikt bei etwas wie Importen oder Änderungen der Methodensignatur (z. B. Umbenennung von Variablen) sehe, frage ich mich, ob es so etwas wie eine sprachbewusste Diff/Merge-Methode gibt, die mit den ärgerlicheren kleinen Änderungen umgehen kann, die auf einem passieren können gemeinsames Projekt. Gibt es irgendetwas, das Konflikte in einer Unix-Umgebung reibungsloser handhabt?

Ich stimme zu, dass es großartig wäre, wenn ein solches Tool existieren würde, aber es gibt keine, die mir bekannt sind. Der Grund, warum ich glaube, dass es keine gibt, liegt darin, dass der Zusammenführungsalgorithmus für jeden SCM (ob git, hg, bzr, svn usw.) auf dem kleinsten gemeinsamen Nenner arbeitet, der einfach nur Text ist. Damit diese SCM-Tools die Sprachsyntax und -semantik wirklich verstehen, müssten sie die Fähigkeit zum Parsen der Sprache beinhalten. Es scheint, dass dies einfach eine zu große Aufgabe für jedes SCM ist, um die Fähigkeit zum Parsen von Java, C#, Python, Ruby, Groovy, C, C++ usw. einzuschließen, ganz zu schweigen davon, dass jede dieser Sprachen unterschiedliche Syntaxen zwischen den Versionen hat (z. B. gab es Java-Generika bis 1.5 nicht). Der SCM müsste also die Fähigkeit beinhalten, zu erkennen oder so konfiguriert werden, dass er weiß, in welcher Sprache und Version der Sprache der Quellcode geschrieben ist.

Ich denke, dass es wahrscheinlicher wäre, dass eine sprachabhängige Zusammenführungsfunktion in einem Zusammenführungstool eines Drittanbieters zu finden wäre (z. B. die Einstellung merge > tool in .gitconfig und die Einstellung ui > merge in .hgrc). Dieses Tool könnte so konfiguriert werden, dass es weiß, dass alle .java-Dateien in Ihrem Projekt in Java 1.6 geschrieben sind, und dann die Parsing-Funktionen im JDK verwendet, um die zu generieren AST und führen Sie eine “tiefe” Analyse durch, ob die Änderung im Kontext dieser Sprache sinnvoll war.

Ich suche genau das gleiche. Diese Anbieter von Zusammenführungstools sollten sich wahrscheinlich mit dieser Art semantischer, sprachbewusster Zusammenführung befassen. Wenn nicht, muss ich einer werden 🙂

Im Moment verarbeite ich als Trick eines armen Mannes manchmal die 3 Dateien (Basis, unsere, ihre) auf ihre „kanonische Form“, indem ich sie durch Eclipse Code Cleanup/Organize Imports/Order Members füttere.

Obwohl begrenzt, funktioniert dies gut: Beim letzten Mal wurde die Anzahl der Konflikte auf ~ 200 in 2 reduziert. Ich plane, dies in ein Skript zu packen und in das Merge-Tool von git einzubinden.

Habe auch ein Skript zur automatischen Auflösung von Java-Importkonflikten geschrieben, das einfach beide Seiten der Importe beibehält und Kommentare hinzufügt, um zu erklären, was vor sich geht und was zu tun ist: „Importe organisieren“.

Vielleicht möchten Sie prüfen, ob alle in Ihrem Team die gleichen IDE-Einstellungen für Dinge wie Importreihenfolge, Formatierung usw. verwenden, um zu vermeiden, dass solche Konflikte überhaupt auftreten.

löst git rebase dieses problem nicht? Alle Variablenumbenennungen werden in den zugehörigen Commits berücksichtigt. Mit git rebase können Sie mit Upstream-Commits synchron bleiben. Solange Sie häufig rebasen (täglich?), sollten Sie solche dummen Konflikte nicht bekommen, und wenn Sie es sind, sind sie wahrscheinlich echte Konflikte und können nicht von einem Java-Grammatik-Parser gelöst werden.

Um es jedem einfacher zu machen, auf dieser Seite zu landen. Diese Frage ist ein Dupe von http://stackoverflow.com/questions/523307/semantic-diff-utilities (es wird in der Hauptfrage beantwortet, ist aber nicht offensichtlich)

Und das aktuelle Tool, das mir bekannt ist (die Antwort für die obige Quest), ist Symantic Merge – https://www.semanticmerge.com

Es gibt auch https://www.devart.com/codecompare das kommt dem nahe, was du willst