2015-06-23 14 views
7

Edit: Ich fügte einige Informationen hinzu, die ich für unnötig hielt, aber nicht ist. ich zwei Zweige haben, A und B. drei Commits in A Nachdem die ich will ändert file.c, um sie in B herauspicken, gibt es auch eine file.h, die in A ~ 1Warum führt diese Kirsche zu einem Merge-Konflikt?

> git cherry-pick A~2 
Success 
> git cherry-pick A~1 
error: could not apply 81e0723... 
hint: after resolving the conflicts, mark the corrected paths 
hint: with 'git add <paths>' or 'git rm <paths>' 
hint: and commit the result with 'git commit' 
> git status 
You are currently cherry-picking commit 81e0723. 
Unmerged paths: 
(use "git add <file>..." to mark resolution) 

    both modified: some/unrelated/file.txt 
    both modified: file.c 
geändert wurde

Wenn man nun einige/unrelated/file.txt anschaut, enthält sie die Änderungen an file.h irgendwo in der Mitte. Das sieht also wie ein Fehler in Git aus. Also werde ich nun die Änderungen einige/unrelated/file.txt manuell rückgängig machen und sie zu file.h hinzufügen.

+0

Für die nicht verwandte Datei, welche Änderungen zeigt es? –

+0

Können Sie ein Commit-Diagramm Ihrer Situation zeichnen? Ich habe das Gefühl, dass eine "Rebase" das Gleiche viel einfacher machen könnte. –

+0

Ich habe das Problem jetzt behoben und werde heute/morgen eine detaillierte Antwort schreiben. – crunsher

Antwort

0

Das Cherry-Picking unterscheidet sich nicht von der Anwendung mehrerer Patches in der Reihenfolge (mit dem Vorteil, vorherige Commit-Nachrichten zu erhalten). Dies führt zwangsläufig zu neuen Blobs - die Sie verifizieren können, indem Sie festhalten, dass er sha's unterscheidet.

Wenn die Zusammenführungszeit kommt, denkt git jetzt, dass es eine andere Geschichte betrachtet, weil es technisch ist, und folglich ein Zusammenführungskonflikt.

1

Es ist möglich, die cherry-pick eine Funktion ändert, die auch früher in B seiner Geschichte geändert worden war, so insbesondere die Veränderungen in A~1 sind Linien, die bereits von verschiedenen sah, was in der Version B ist und git kann nicht Sehen Sie, wo in B die Änderungen der Kirschpickel gelten.

Es ist auch möglich, dass der Kontext git für die Änderungen findet, hat böse Zwillinge irgendwo anders im Code (sagen wir, mehrere Zeilen mit nichts als selbständige schließende Klammern), und andere Änderungen haben das echte entsprechende Original in Ihrem Code weit genug von wo es in A~1^ war, dass die Jagd nach dem Kontext in B etwas anderes stattdessen findet. Das Handbuch schlägt vor, den Kirschpflock abzubrechen und das Wiederholen mit git cherry-pick -Xpatience könnte genug sein, um Ärger mit denjenigen zu vermeiden, die eine normalerweise unvernünftige Menge an Zeit ausgeben, um zu versuchen, in einem Meer von Klammern verloren zu gehen. Here's probably a good place to start if you want details on how that really works.