Log eines externen git-Repositories auslesen

Für sonstige Unterhaltungen, welche nicht direkt mit Lazarus zu tun haben
Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Log eines externen git-Repositories auslesen

Beitrag von 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
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Log eines externen git-Repositories auslesen

Beitrag von 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?

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Log eines externen git-Repositories auslesen

Beitrag von m.fuchs »

mse hat geschrieben: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.

mse hat geschrieben:
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.

mse hat geschrieben:
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.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Log eines externen git-Repositories auslesen

Beitrag von mse »

m.fuchs hat geschrieben: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

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Log eines externen git-Repositories auslesen

Beitrag von 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
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Log eines externen git-Repositories auslesen

Beitrag von m.fuchs »

mse hat geschrieben: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. :D
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: Log eines externen git-Repositories auslesen

Beitrag von 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.
mse hat geschrieben: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').
log1.png

log2.png

Warf
Beiträge: 1908
Registriert: Di 23. Sep 2014, 17:46
OS, Lazarus, FPC: Win10 | Linux
CPU-Target: x86_64

Re: Log eines externen git-Repositories auslesen

Beitrag von 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.


af0815 hat geschrieben: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

Antworten