Log eines externen git-Repositories auslesen

[af0815]

Die Frage war aber ursprünglich

Code: Alles auswählen

Ich möchte per Befehl die Logeinträge eines externen Repositories abfragen.

. Damit ist der Aufwand des Logs bei SVN im Gegensatz zum Aufwand bei Git zu betrachten.

Andreas

[mse]

Im Gegensatz zu SVN ist git ein verteiltes Versionsverwaltungssystem ohne dedizierten Server. Darum arbeitet es grundsätzlich mit lokalen Repo-Kopien, welche aber in der Regel nicht aufwendiger als ein einfacher SVN Checkout sind. Einige aus SVN gewohnten Vorgehensweisen machen mit git keinen Sinn, wie auch einige mit git üblichen Arbeitsweisen mit SVN keinen Sinn machen.
Um ein aktuelles Log der master branch des remote Repositories zu bilden macht man mit git z.B.

Code: Alles auswählen

 
git fetch origin
git log origin/master
 

Scheint mir nicht wahnsinnig aufwendig?

[m.fuchs]

git ist nicht SVN. Ein git repo mit der kompletten History ist meistens kleiner als ein SVN checkout einer einzigen Version.
Die Dateigrösse des FPC git-clone Verzeichnisses ist 244 Mb (enthält die gesamte History!).
Mein FPC fixes_3_0 SVN checkout Verzeichnis im Gegensatz dazu hat eine Dateigrösse von 797 MB.

Hm, SVN-Trunk vs. GIT-Clone ist bei mir etwa gleich groß.
Ja, es ist natürlich immer noch effizienter da die gesamte Historie mit drin ist. Trotzdem will ich nicht für Projekte die ich nicht bearbeite, nicht den Quellcode bei mir lokal haben.

Ich brauche wirklich nur Infos über neue Version, damit ich mir bei Bedarf die Code-Änderungen ansehen kann.

Wie schaust du dir die Änderungen an?

Das wäre dann das nächste Problem. Da es kein remote-log gibt wird es auch kein remote-diff geben.

Da es das nicht ist, und es keinerlei Vorteile gegenüber SVN gibt, wird es halt nicht eingesetzt.

Michael, das ist nun kompletter Unsinn.

Nein wieso? Ausgangspunkt war die Bitte eines Entwicklers von svn auf git zu wechseln. Maximal hätte ich git parallel erlaubt. Aber da entscheidende Funktionen fehlen und svn unsere Bedürfnisse abdeckt wird auch das nicht passieren.
Und auf irgendwas zu wechseln, nur weil es "der neue heiße Scheiß [tm]" ist sehe ich gar nicht ein. Der einzige wirkliche Vorteil ist die Möglichkeit offline zu committen. Naja, das ist bei uns eher uninteressant und wiegt niemals die Nachteile (dazu zählt auch die Eingewöhnung an neue Konzepte) nicht auf.

[mse]

Ja, es ist natürlich immer noch effizienter da die gesamte Historie mit drin ist.

Plus *alle* Branches und Tags!

Nein wieso?

Ich habe mit SVN viele Jahre gearbeitet und arbeite auch mit git seit vielen Jahren. Meine Erfahrung zeigt, dass die Arbeit mit git viel praktischer ist und auch mehr Möglichkeiten bietet.

Maximal hätte ich git parallel erlaubt.

Dafür gibt es git svn.
https://git-scm.com/docs/git-svn

[af0815]

Das mit den lokalen Kopien wäre ja nicht das Problem an sich, wenn man zB ein clone mit depth 0 machen kann. Also alles an Verwaltungsinfo, aber ohne die Objekte. Dann wäre es effezient.

Für mich hat es keine weiteren Auswirkungen, da Github auch svn versteht Keine Ahnung ob Gitlab das auch macht.

Andreas

[m.fuchs]

Ich habe mit SVN viele Jahre gearbeitet und arbeite auch mit git seit vielen Jahren. Meine Erfahrung zeigt, dass die Arbeit mit git viel praktischer ist und auch mehr Möglichkeiten bietet.

Mag ja sein, dass es für dich passt. Ich habe bisher noch kein Argument gehört, dass in mir den Wunsch erweckte es einzusetzen.
Aber mehrere Stolperfallen erlebt, die eine tiefe Abneigung auslösen.

[mse]

Hast du meinen Hinweis auf "git svn" gelesen? Vielleicht gibst du ihn an deinen Entwickler weiter, damit kann er mit git arbeiten ohne dass du etwas ändern musst.

Einige aus SVN gewohnten Vorgehensweisen machen mit git keinen Sinn, wie auch einige mit git üblichen Arbeitsweisen mit SVN keinen Sinn machen.

Zur Illustration, die Aufgabe den Fortschritt eines remote Repo abzufragen stellt sich mit git in dieser Form gar nicht. Man wählt die zu vergleichende remote branch in der 'L'-Spalte und sieht im Log-Fenster die remote commits mit den markierten Ständen der branches. Im diff-Fenster links sieht man die zur aktuellen Log-Zeile gehörenden Patchdaten (Einstellung 'Commit Diff') oder die Differenz zur eigenen branch ('Difference Diff').

[Warf]

Verwendest du eigene Hoster oder sowas wie Github, Gitlab, etc.? Sowohl github als auch gitlab haben soweit ich weiß eine web API (also standardisiertes HTTP interface) was genau dafür gemacht ist, was du vorhast.

Git hat schon seine Vorzüge, aber auch (kleine) Nachteile.

Da muss ich jetzt mal meinen senf dazu geben. An sich ist git nicht gut. Es gehört zum Git Flow Commits, und damit arbeitsinformationen, zu löschen (z.B. Rebase), was praktisch das komplette gegenteil von dem ist was Git eigentlich tuen sollte. An sich eigentlich ein Ausschlusskriterium für ein Versionskontrollsystem (Da die idee ist jede änderung zu konservieren und nachvollziehen zu können). Git ist besser als SVN in dem Sinne wie ein neuer VW Polo besser ist als ein 30 Jahre alte Mercedes E - Klasse. Aber git hat nicht nur kleine Nachteile, sondern gravierende.

Der hauptgrund warum ich so viel git verwende ist das es einfach jeder Verwendet (und mindestens für Uni und Arbeit muss ich git verwenden) und ich daran mittlerweile gewohnt bin. Wirklich gut ist es aber nicht, zumindest im vergleich zu echten alternativen (also anderen verteilten Systemen) wie Mercurial ist es eigentlich eine schlechte option. Aber wenn man mit dem rest der Welt kompatibel sein will muss es entweder Git oder SVN sein, und da ist mir das dezentrale git lieber