Mainline übergeordnete Nummer an, wenn cherry picking merges

Nehme an, dies ist meine git Geschichte

 Z 
/
A -- C -- D 
\ /
B

Mein KOPF ist derzeit bei Z. Ich möchte zum cherry-pick B und C. Wenn mein Verständnis richtig ist, sollte ich dies tun:

git cherry-pick B
git cherry-pick C -m 1
git commit --allow-empty

Funktionierte es in meinem Fall, weil C ist ein no-op (daher die leeren Begehen, danach brauchte ich den commit aus anderen Gründen), aber ich Frage mich, was die parameter nach -m tut. Hier ist, was ich gelesen habe von die docs:

-m Eltern-Anzahl

--mainline Eltern-Anzahl

In der Regel können Sie nicht cherry-pick einen merge, weil Sie nicht wissen, welche Seite der merge sollte als die Hauptschnur. Diese option gibt die übergeordnete Nummer (beginnend mit 1) der Fernbahn und ermöglicht cherry-pick nachspielen, die änderung im Vergleich zu dem angegebenen parent.

In meinem Fall C hat zwei Eltern, aber wie kann ich wissen, was man 1 und 2, und noch wichtiger, Wann ist es egal, wenn ich wählen, 1 oder 2?

  • Dies scheint hauptsächlich ein Duplikat der stackoverflow.com/questions/9229301/... ... oder ist deine Frage wirklich, ob man bestimmen kann, die übergeordnete Nummer aus dieser graph zeichnen? (Antwort: Nein), oder: gibt es ein Determinismus über 1. vs 2. Elternteil bei der Zusammenführung? (Antwort: ja, nicht genug Platz im Kommentar für mehr).
  • Was wollen Sie mit Ihrer resultierenden die Geschichte Aussehen? Wollen Sie C' haben Eltern Z und B'? Warum brauchen Sie, um cherry-pick der C wenn Sie bereits handverlesene B?
  • Ich möchte, dass meine entstehende Geschichte auf, die Filiale zu A -- Z -- B' -- C' (wenn es einfacher für C' haben mehrere Eltern, die funktioniert auch). Ich muss cherry-pick, die Begehen für die die Informationen über den Autor trotz "leer"
  • Ich tatsächlich gelesen, dass die Frage vor dieses posting und die Antwort besagt, dass der merge-commit stellt mehrere verschiedene diffs und hat mehrere Eltern mit einem Beispiel -m 1, aber nicht wirklich erweitern, was der Unterschied ist. Die Erweiterung auf Ihre zweite Frage und vielleicht zeigt die Unterschiede zwischen den 1. vs 2. Elternteil wäre wirklich hilfreich, denke ich.
InformationsquelleAutor rink.attendant.6 | 2016-10-20
  1. 21

    Mein Verständnis basiert off die Antwort ist, dass Eltern 1 ist der Zweig zusammengeführt in und Elternteil 2 ist der Zweig zusammengeführt aus. Also in deinem Fall, Elternteil 1 ist A und Elternteil 2 ist B. Da Sie eine cherry-pick ist wirklich der Anwendung der diff zwischen zwei commits, die Sie verwenden -m 1 nur die änderungen von B (weil der Unterschied zwischen A und C enthält die änderungen aus B). In deinem Fall ist es wahrscheinlich egal ist, da Sie keine commits zwischen A und C.

    Also ja, -m 1 ist, was Sie wollen, und das ist wahr auch wenn es extra commits zwischen A und C.

    Wenn Sie wollen, um die neue Geschichte sich ein wenig mehr wie die original-Geschichte, es ist ein weiterer Weg, um dies zu tun:

    git cherry-pick B
git checkout Z
git merge --no-ff --no-commit B
git commit --author="Some Dev <[email protected]>" --date="<commit C author date>"

    (Wenn nötig, können Sie einen neuen Zweig für B bevor Sie cherry-picking.)

    Diese behält der Autor der Informationen, sollte Ihnen eine Geschichte, die wie folgt aussieht:

        B'
   / \
  Z -- C'
 /
A -- C -- D
 \  /     
  B
    • Das ist richtig: die erste parent einer normalen merge ist die Niederlassung Sie sind auf der auf der Zeit, die Sie den Seriendruck, so dass -m 1 gibt immer "die Veränderungen, die in über die "merge". Es gibt keine Möglichkeit zu sagen, einfach aus einem graph zeichnen, aber, da diese Informationen verloren gehen der zwei-dimensionalen-isierung Prozess. (Das heißt, wir können zeichnen die Grafik aber uns gefällt: der graph-Topologie hat keine Eltern bestellen. Eltern-Bestellung ist etwas, Git Hinzugefügt. Wir brauchen die Fähigkeit, halten wenig zählen zahlen auf jeder ausgehenden Bogen von jedem Knoten zu repräsentieren Git ' s Eltern-number-Konzept.)
    • Die guten Punkt über den Graphen. Ich in der Regel davon ausgehen, dass, wenn es gezeichnet wird, wie ein Dreieck (eher als ein Diamant, wie in Ihrer Antwort), die der Autor angibt, welcher Zweig zusammengeführt wurde, die.
    • Beachten Sie, dass die Eltern, um auch scheint die Reihenfolge der Anzeige auf der Merge: Linie mit git show <commit>.
    InformationsquelleAutor Scott Weldon
  2. 2

    Habe ich von Ihnen positiv bewertet werden Scott Weldon ' s Antwort, das ist richtig, aber ich möchte nur hinzufügen, ein Versuch, die ASCII-Kunst, die beinhaltet übergeordnete Nummerierung. Gegeben ein graph, der wie folgt aussieht:

           B
      /\
...--A   D--...
      \ /
       C

    wir können sagen, dass der Knoten D ist ein merge-commit, aber wir können nicht sagen, ob B oder C ist das erste übergeordnete D. Einer der beiden ist unbedingt die ersten Eltern, und die andere ist die zweite. Wenn wir also wissen müssen, müssen wir beschriften der Zeichnung, das braucht mehr Raum. Hier ist ein solcher Versuch.

             B
       /  \²
...--A       D--...
       \   /¹
         C

    Sehen wir nun, dass aus irgendeinem Grund,1, die ich gezeichnet habe die Grafik "upside down": das Begehen C ist in der Tat die ersten Eltern von D, während die commit - B ist der zweite Elternteil.

    Ist es möglich, beliebige verschmilzt mit unterer Ebene ("plumbing" - Befehle). Insbesondere git commit-tree nur dauert jedoch viele -p Argumente, die Sie es nennen wollen, in der Bestellung geben Sie Ihnen, und macht einen neuen commit mit der gegebenen verpflichtet wie Ihre Eltern. Geben Sie ihm eine -p und es macht einen normalen Begehen mit nur einem Elternteil. Geben Sie keine -p Argumente, und es macht ein root-commit. Geben Sie es 155 verschiedene -p Argumente (alle müssen natürlich lösen, um gültige commit-IDs) und es macht riesigen octopus-merge-commit.

    Den git merge Befehl, jedoch, macht immer seine neuen commit mit dem ersten Elternteil wird der aktuelle HEAD (daher der current-Zweig, wenn auf einem ast). Der zweite Elternteil, für eine standard-zwei-Eltern-merge, kommt aus .git/MERGE_HEAD, in die git merge schreibt das der andere commit-ID. Wenn der merge-Konflikt ist, oder der merge-commit verzögert mit --no-commit diese MERGE_HEAD - Datei ist in der Tat die nur Ort, der commit-ID ist verfügbar.

    (Wenn git merge macht eine octopus-merge, mit dem -s octopus Strategie—diese Strategie ist gezwungen, auf für solche Zusammenführungen—und mehrere weitere Eltern, es bricht ab und hinterlässt keine Spuren, wenn es merge-Konflikte, also der Konflikt Fall tritt nie ein. Ich habe nicht versucht, die Kombination --no-commit mit einem octopus-merge, aber das wäre logisch, verlassen Sie den 2. durch die N ' te Eltern in MERGE_HEAD, wenn Git ermöglicht diese überhaupt.)

    1Eigensinn.

    InformationsquelleAutor torek
Schreibe einen Kommentar