Get git log Bereich von Remotezweig

Question

Abrufen der Protokolle innerhalb einer bestimmten Tag-Bereich wie erwartet funktioniert:

git log v1..v2 --oneline 

Allerdings möchte ich die Tag-Bereich Protokolle von origin/master. Wenn ich den Tag-Bereich und Remote/Branch-Argumente zur Verfügung stelle, bekomme ich nicht wie erwartet.

git log origin/master v1..v2 --oneline 

Die Ausgabe ist die gleiche, als wenn v2 überhaupt nicht zugeführt wird. In der Tat, wenn v2 entfernt wird, ist die Ausgabe von v1 zu HEAD von origin/master.

Wie kann ich sicherstellen, dass dieser Befehl das TAG-Bereichsargument respektiert?

Git Version 2.9.0

Answer 1

Das Problem ist, dass dies:

git log origin/master v1..v2 --oneline 

bedeutet nicht, was Sie denken, es bedeutet.

The gitrevisions syntaxv1..v2 ist die Abkürzung für v2 ^v1. Wenn Sie dies mit origin/master kombinieren, geben Sie Git alle drei Selektoren:

• schließen jede v2 erreichbar von Tag begehen;
• umfassen alle commit erreichbar von Remote-Tracking-Zweig Name origin/master;
• aber exclude (aus der ganzen Liste) alle und alle solche Commits, die sind erreichbar von das Tag v1.

Angenommen, Sie diese Grafik haben:

   o--o--o <-- br1 
      /
...--o--A--B--o  <-- br2 
     \ 
      o--o--o  <-- br3 

wo jeder Runde o stellt ein begehen. Die Namenbr1, br2 und br3 jeweils zeigen auf ein bestimmtes Commit, das ist die Spitze commit jedes Zweiges.

Es sind die eigentlichen Commits selbst, die auf ihre vorherigen Commits zurückführen. Ich habe zwei bestimmten Commits gegeben A und B Ein-Buchstaben-Namen hier: diese Festschreibungen sind extra interessant, weil zu begehen B auf beiden Filialen ist br1 und br2 und begehen A ist auf allen drei Zweige. Dies liegt daran, dass zwei Commits "nach" B vorliegen, die beide auf B verweisen. Commit B ist die Merge-Basis der Niederlassungen br1 und br2, so dass es auf beiden Zweigen ist.Ebenso B Punkte zurück auf A, aber so begehen ein am Zweig br3: commit A wird die Verschmelzungs Basis von br3 und br2 (und auch die Zusammenführung von Basis br3 und commit B). So ist A auf beiden Zweigen br2 und br3, und da B auf br1 ist, ist A notwendigerweise auch auf br1.

Die Idee der folgenden begeht zurück (nach links in diesem Diagramm) in ihre Eltern Commits ist, wie Git diese Erreichbarkeit bestimmt.

Denken Sie an v1 und v2 als Bezeichnungen für bestimmte Commits, genau wie Branch-Namen, denn so macht Git sie arbeiten. Tag-Namen und Branch-Namen sind nur Namen für ein bestimmtes Commit. Der Unterschied besteht darin, dass ein Tag-Name global ist - Ihr Tag v2 sollte mit allen anderen übereinstimmen v2 - und diese Tag-Namen sind , die nicht verschoben werden sollen. Ein Zweigname wie br2verschiebt automatisch, wenn wir der Verzweigung ein neues Commit hinzufügen. Ein Tag-Name nicht.

Lassen Sie uns ein weiteres Diagramm zeichnen, diesmal mit einem v1 und v2 drin. Ich habe nicht das Repository so dass diese von Ihre Repository keine genaue grafische Darstellung ist, aber es wird, wie ich hoffe, zeigen das Prinzip:

...--o--v1--A--B--C--D--v2 <-- branch 
     \   \ 
      F--G--H--I---J--K <-- origin/master 

Wenn wir sagen, dass wir ^v1 Git fragen zu „malen verpflichten v1, und alle früheren Commits, rot vorübergehend ". Dies verhindert, dass sie von den übrigen von uns bereitgestellten Namen oder IDs ausgewählt werden. Dann, wenn wir v2 sagen, fordern wir Git auf, "commit v2 und frühere unbemalte Commits, vorübergehend grün zu malen". Diese Farben , C, B und A, aber stoppt danach, wie v1 ist rot lackiert.

Hinzufügen origin/master sagt Git zu malen commit K grün, und arbeiten rückwärts. Commit J ist ein verschmelzen Commit, so Git Farben J grün und beginnt dann zu malen beide Eltern, und I. Irgendwann geht es wieder zurück zum bereits roten v1, also hört es dort auf.

Schließlich betrachtet Git alle grün bemalten Commits. Das ist alles von A bis K plus v2.

Wenn wir v2 auslassen -wenn wir fragen

git log ^v1 origin/master 

für instanz wir nicht mehr v2 selbst sehen begehen, wie es nie vorübergehend grün gestrichen wurde; aber wir werden immer noch alle A bis K sehen.

Beachten Sie, dass dies - die ^v1 origin/master Form - entspricht v1..origin/master. Ich denke, Sie schreiben origin/master v1.. oder v1.. origin/master (beachten Sie den Raum nach der ..!); In diesem Fall wird der Name "missing" mit HEAD ausgefüllt, der Ihr aktuelles Commit angibt.Diese anderen Befehle verwenden also als rote und grüne Farben.

Nebenbei: alle "rote Farbe" (Hat-Präfix) Operationen sind zuerst getan; oder äquivalent, Sie können dies als "malen Sie rot über grün, aber nie grün über rot malen" und tun sie in jeder Reihenfolge. (Und denken Sie daran, dass die ganze Farbe wieder weggespült wird, gleich nachdem der Git-Befehl beendet ist :-))