2009-05-12 12 views

Antwort

4

Ich denke, es ist eine Reihe. Der Befehl ".." zeigt Ihnen die Commits zwischen dem letzten Commit des Ursprungs/Masters und dem letzten Commit in dem Zweig, an dem Sie gerade arbeiten.

Sie auch den Zweig Sie, indem es nach dem .. vergleichen wollen angeben können, so wird es

git log origin/master..<branch_name> 

Sie können auch die commit Bezeichner verwenden werden die Ausgabe, zum Beispiel zu filtern:

git log 663f4c..fec6b 

Versuchen git help log andere Optionen, um zu sehen :-)

46

Mit git log (und alle anderen Git-Befehle, die ein ähnliches Argument Satz nehmen), es ist eine Spezifikation, wie man eine Reihe von Revisionen findet, ja. Denken Sie daran, dass in Git 'allgemeiner Welt ein Teilgraph des Revisionsgraphen gemeint ist - für die meisten Leute bedeutet das im Allgemeinen nur eine Reihe von Revisionen in einer Liste. (Und wenn Sie nicht viel tun, wenn es Verzweigungen gibt, vereinfacht sich das auch in Git).

Die Revisionsspezifikation enthält eine Reihe von positiven Referenzen (Startpunkte) und negative Referenzen (Stopp-Punkte) sowie zusätzliche Filter (Anzahl der Revisionen begrenzen, Grep-Commit-Text usw.). Git beginnt mit den positiven Referenzen und geht durch den Revisionsverlauf zurück und stoppt, wenn es Revisionen trifft, die von den negativen Referenzen erreichbar sind (nicht notwendigerweise nur, wenn es eine der negativen Referenzen selbst erreicht).

Es ist vielleicht ziemlich verwirrend, dass es verschiedene Kurzschriftnotationen gibt, die sich entwickelt haben, um das alles einfacher zu machen und irgendwie auch zu verwirren - ich musste eine ganze Weile damit verbringen herauszufinden, was genau "Master .. maint "," maint..master ", usw. gemeint und wann welches zu verwenden ist.

Wenn Sie nur "Herkunft/Master" sagen, dann bedeutet das, dass "Ursprung/Master" eine positive Referenz ist und es keine negativen Referenzen gibt. Git beginnt also beim Ursprung/Master und geht zurück durch alle die Revisionen verfügbar - Sie erhalten die komplette Geschichte der Herkunft/Master.

"origin/master .." ist eine Abkürzung für "origin/master..HEAD", die so aussieht, als ob sie "von Herkunft/Master bis HEAD" bedeutet. Was es effektiv macht. Es kann umgeschrieben werden als "HEAD^Herkunft/Master" oder "HEAD --not Herkunft/Master". In diesem Fall ist HEAD eine positive Referenz und "Ursprung/Master" ist eine negative Referenz. Also beginnt Git bei HEAD und geht durch den Graphen zurück, bis es auf eine Revision trifft, die vom Ursprung/Master aus erreichbar ist. Es ist wahrscheinlich, dass es tatsächlich auf den Ursprung/Meister trifft. Beachten Sie, dass alle Referenzen inklusive sind - die positiven Referenzen selbst werden ausgegeben und die negativen Referenzen nicht (es sei denn, Sie geben --grenze an, und dann werden sie markiert). Das bedeutet, dass "origin/master..HEAD" nichts ausgibt, wenn HEAD und origin/master dieselbe Revision haben.

Also, wenn Sie ein paar lokale Commits auf dem Upstream-Version von Situation Sie diese Art haben gemacht haben:

[email protected]:~/src/git <master>$ git log --pretty=oneline --abbrev-commit --decorate -n 4 
ea3107d (refs/heads/master) Add another dummy comment 
869c260 Add dummy comment 
6345d7a (refs/remotes/origin/master, refs/remotes/origin/HEAD) Merge branch 'maint' 
be427d7 allow -t abbreviation for --track in git branch 

Und nun „git log origin/master ..“ bedeutet git zu BEGINN HEAD (ea3107d), der vom Ursprung/Master nicht erreichbar ist, so druckt es.Dann geht es zurück zu HEADs Eltern (869c260), was immer noch nicht der Fall ist. Dann ist der nächste Elternteil 6345d7a, der ist Herkunft/Master, so dass es aufhört.

Beachten Sie, dass "git log ..origin/master" das Gegenteil tut - versucht, von Ursprung/Master zu HEAD zurückzugehen. In diesem Fall wird nichts gedruckt. Aber wenn ich "Ursprung/Wartung" auschecke, würde es die Revisionen auf Ursprung/Meister drucken, die nicht auf Herkunft/Wartung waren: so im Allgemeinen versuchen, "A..B" als "Revisionen in B, die nicht sind in A ", und bedenke, dass das Weglassen von A oder B" HEAD "bedeutet.

Nur für extra super duper Verwirrung gibt es auch eine Notation "A ... B". Also vergiss nicht, die Anzahl der Punkte zu zählen! Im Falle von A und B, die sich in einer Revisionslinie befinden, gibt es keinen wirklichen Unterschied. Aber was "A ... B" bedeutet, ist die Revisionen in A oder B, die sich in keiner der Zusammenführungsgrundlagen für A und B befinden. Wenn sich also A und B in divergierenden Zweigen befinden, werden alle an beiden vorgenommenen Commits angezeigt seit sie auseinander gegangen sind.

Die "lange Form" für einen Revisionsbereich ("B --not A") können Sie Dinge wie "alle Revisionen für lokale Niederlassungen, die nicht auf einem Remote-Tracking-Zweig sind" ("--branches - -nicht --ferne "). Diese Argumentliste wird von vielen Git-Befehlen analysiert ("git rev-list" ist der Kern), einschließlich gitk. Sie können also "gitk --branches --not --remotes" verwenden, um Ihre lokalen Änderungen grafisch darzustellen.

Und schließlich für Mega-Bonus Verwirrung, Befehle wie "git diff" akzeptieren die gleiche Art von Kurzschrift-Syntax, aber es bedeutet nicht (ganz) das Gleiche. git diff nimmt tatsächlich zwei Revisionen und vergleicht sie, was nicht dasselbe ist wie ein Bereich - denken Sie daran, dass ein Revisionsbereich in Git ein Untergraph ist, nicht nur eine Liste. "git diff A..B" ist äquivalent zu "git diff A B". "git diff A ... B" bedeutet "zeige die Änderungen in B, da es von A abweicht". Verwirrend? Nur ein bisschen: zum Beispiel bedeuten "git log A ... B" und "git log B ... A" dasselbe, aber "git diff A ... B" und "git diff B ... A "nicht.

+1

Siehe git-rev-list (1) manpage, die erklärt .. syntax –

20
git log origin/master 

möchte (fake-Befehl) sein:

git log INITIAL..origin/master 

While:

git log origin/master.. 

ist:

git log origin/master..HEAD 
+0

Das ist eine nette, kurze Antwort, wenn Sie nach einer schnellen Antwort suchen, obwohl die Antwort von araqnid deutlich robuster und erklärender ist! – patrickvacek

+0

Ich sehe nicht, welchen Wert die Antwort von araqnid bietet. Mine beantwortet die gestellte Frage. – FelipeC

+0

Ihre Antwort beantwortet die Frage, daher habe ich sie aktualisiert. Ich habe auch araqnids Antwort aufgewertet, weil sie auch die Frage beantwortet, aber vollständiger. Ich schätze die Einfachheit Ihrer Antwort, aber die andere erklärt die Befehle mit mehr Details, was auch nett ist. – patrickvacek

1

Mein eigener mnemonic Weg, um die Semantik zu erinnern ..

Ich

denken ‚git log start..end‘ in Bezug auf die Datumsbereich, wo Startden älteren Teil der Geschichte darstellt und Ende für die jüngeren Geschichte. Doch im Gegensatz zu Datumsbereich, verpflichtet Bereich ist kein linearer walkback und hat keine Beziehung zu tatsächlichem Zeitpunkt, sondern ein Satz Subtraktion, dh:

(commits reachable from "end") - (commits reachable from "start") 

Denken Sie daran, dass der Start (ausgeschlossen wird) in einem Commit Bereich stellt eine Menge von einem oder mehreren Commits dar, nicht ein einzelnes Commit.

Es bezieht sich effektiv auf alle Commits, die zwischen 'Start' (exklusiv) und 'Ende' (inklusive) erstellt wurden.