Grundatzdiskussion um git

PMc

Well-Known Member
Politisch führt da natürlich kein Weg dran vorbei. Und die Opfer (also die Leute, die es dann praktisch benutzen müssen) interessieren in der Politik eh keinen.

Soweit ich einen Blick auf git geworfen hab, entspricht das genau dem Chaoshaufen, der Linux ist und schon immer war - was der entscheidende Grund war, dass ich Linux 1995 in die Tonne gehauen hab.

Der Auslöser war damals das ping Kommando, und es ging darum, ein paar DSL Links auf Funktion zu überwachen. Wie man der FreeBSD manpage entnehmen kann, hat ping zwei verschiedene Returnwerte: 1 bedeutet, es funzt nicht. 2 bedeutet, Gegenstelle antwortet nicht.

Bei Linux war das anders: dort fand man es lustig, diese Werte zum Jonglieren zu nehmen. Genauer gesagt: im Quellcode unter /usr/src waren sie genau umgekehrt verwendet als im ausführbaren Binary.
Nun möchte ich aber, wenn ich das Verhalten einer Software nicht verstehe, genau unter /usr/src nachlesen, was diese Software tut. Und mehr noch, wenn mir das Verhalten nicht gefällt, möchte ich unter /usr/src das entsprechende Bit ändern, "make install" sagen, und fertig - und jedenfalls nicht erst eine Forschungsreise antreten dahingehend, wo vielleicht irgendwie der tatsächlich korrekte Code aufzutreiben sein könnte.

Und das ist exemplarisch. Nicht nur ist Linux ein zusammenkopiertes Sammelsurium von allem möglichen Utilities von irgendwoher ohne eine autoritative Linie oder gar eine konsistente Versionsverwaltung darin, sondern das, was man dann kredenzt kriegt, ist sogar in sich selber nicht schlüssig, d.h. praktisch nicht brauchbar.

Und git ist dann -später- just zu dem Zweck entwickelt worden, um genau eine solche Arbeitsweise, nämlich einen Chaoshaufen, zu unterstützen. Die Diskussion war natürlich politisch, die Schlagworte waren "the cathedral and the bazaar" - man hat die herkömmliche kommerzielle, streng reglementierte Softwareentwicklung mit der linux-typischen Arbeitsweise des Chaoshaufens verglichen, und ist auf dasselbe gekommen, was dann später auch die Agile-Fans verbreitet haben: dass die klassische Software-Entwicklung zu unflexibel und zu wenig innovativ ist.

Aber wie ein Bazaar funktioniert, weiß auch jeder, der schon mal in Asien war: entweder man hat da Verwandte. oder man wird übers Ohr gehauen.

Dass FreeBSD damals schon das beste aus beiden Welten kombiniert hatte, und, vor allem, wunschgemäß funktioniert hat und nutzbar war, ist natürlich niemandem aufgefallen. Aber das hatten wir ja alles auch schon vorher: wenn sich jemand mal wirklich hinsetzt und was taugliches macht, dann geht das unter und wird "vom Markt verdrängt"; siehe Video2000 und viele ähnliche Beispiele. Und nach hundert Nachbesserungen und Flickschustereien kriegt man dann das Nötige doch irgendwann mal getan, und vor allem: Leute haben derweil eine Beschäftigung.

Kann man natürlich so machen. Muss man aber nicht.

Trotzdem danke ich aus dem Bauch heraus, dass eine Migration von svn zu git zwar zu Diskussionen und Gemotze führt, aber doch durchsetzbar ist.

Genau - eine rein sozialpolitische Bewertung unter Ausklammerung der fachlichen Aspekte und Verzicht auf Technikfolgenbewertung.

Ich meinte mehr die Community außen herum. Auch die ist bei weiten nicht so erzkonservativ, wie man auf den Blick meint, aber es gibt eine kleine und sehr Laute Gruppe, die scheinbar schon aus Prinzip jede größere Änderung ablehnt. Es ist zumindest auf den Mailinglisten auffällig, dass in jeder Diskussion immer die gleichen Namen "dagegen" sind.

Ein Problem ist, dass schon der Begriff "konservativ" heute negativ besetzt ist - auch das ist freilich eine rein sozialpolitische Bewertung ohne technisch-fachlichen Bezug.

Und das andere Problem ist schlicht das, dass man es sich leisten kann: man hat nicht mehr die Hände voll damit zu tun, dass etwas überhaupt mal zum Funktionieren gebracht wird, sondern kann sich sozialpolitische Eskapaden leisten. Man ist dekadent.

Nun ist es in meinen Augen so, dass die Frage zwischen Fortschritt und Beibehaltung des Bestehenden bei Software immer eine Gradwanderung ist. Auf der einen Seite möchte man keinen Fortschritt des Fortschritts willens, vor allem nicht in einem per Design eher konservativen System wie FreeBSD. Sonst wären wie nicht FreeBSD sondern Linux oder Windows, was im Moment jedes halbe Jahr größere nutzersichtbare Änderungen einbringt. Aber auf der anderen Seite muss man auch mit der Zeit gehen.

Muß man das? Liegt darin irgendein Wert-an-sich?
Wie wäre es, stattdessen technisch-fachliche Bewertungen vorzunehmen? Aber ja, das wäre dann das, was man früher mal "deutsche Ingenieurarbeit" nannte - und das will man ja auch nicht mehr (außer im Ausland).
 
Ich benutze git schon gut 10 Jahre sowohl privat als auch geschäftlich und hatte noch nie irgendwelche Probleme damit. 2 Repositories haben auch schon mehrere GB Größe. Privat, um meine eigenen Dokumente und Dateien über mehrere Rechner zu verteilen und geschäftlich als Software-Entwickler. Beteilige mich auch hier und da über github/lab an diversen OpenSource Projekten. Auch hier keinerlei Probleme.

Und den Workflow den git gerade im Zusammenhang mit github/lab so bietet ist mit Versionsverwaltungen wie SVN gar nicht umsetzbar. Es hätte von mir aus auch Mercurial damals werden können, statt git. Aber wie das so ist mit Projekten die zeitgleich entstehen: Der Markt entscheidet sich am Ende für eines. Nehmen tun sich beide nicht viel. Beides dezentrale CVS.

Wenn deine einzige Kritik an git ist, dass es aus dem Linux-Lager kommt, dann wundere ich mich über deine Frage nach einer "technisch-fachliche Bewertungen" der Dinge.
 
Ich benutze git schon gut 10 Jahre sowohl privat als auch geschäftlich und hatte noch nie irgendwelche Probleme damit. 2 Repositories haben auch schon mehrere GB Größe. Privat, um meine eigenen Dokumente und Dateien über mehrere Rechner zu verteilen und geschäftlich als Software-Entwickler. Beteilige mich auch hier und da über github/lab an diversen OpenSource Projekten. Auch hier keinerlei Probleme.

Und den Workflow den git gerade im Zusammenhang mit github/lab so bietet ist mit Versionsverwaltungen wie SVN gar nicht umsetzbar. Es hätte von mir aus auch Mercurial damals werden können, statt git. Aber wie das so ist mit Projekten die zeitgleich entstehen: Der Markt entscheidet sich am Ende für eines. Nehmen tun sich beide nicht viel. Beides dezentrale CVS.

Wenn deine einzige Kritik an git ist, dass es aus dem Linux-Lager kommt, dann wundere ich mich über deine Frage nach einer "technisch-fachliche Bewertungen" der Dinge.

Das ist nicht meine einzige Kritik, denn ich kritisiere es überhaupt nicht. Und "Lager" interessieren mich grundsätzlich nicht, mich interessieren Ergebnisse.

Wenn man für seine eigenen Zwecke ein VCS braucht, dann kann man da sowieso jedes mit genügendem Funktionsumfang nehmen, denn die erforderliche Disziplin bleibt einem selber überlassen.
Wenn man jedoch eine Codebase hat, an der hunderte Leute mitarbeiten, und in der sich zigtausende zurechtfinden müssen, dann wird sich das VCS unweigerlich auch auf den Arbeitsstil auswirken.

Was verstehst Du unter einem "Workflow"?
 
Das ist nicht meine einzige Kritik, denn ich kritisiere es überhaupt nicht. Und "Lager" interessieren mich grundsätzlich nicht, mich interessieren Ergebnisse.

Rundherum Linux und Git Entwicklung als "Chaoshaufen" zu bezeichnen ist keine Kritik? Was ist denn dein Problem mit git? Du hast zwar viel geschrieben, aber da war leider keinerlei "technisch-fachliche Bewertungen" dabei.

Was verstehst Du unter einem "Workflow"?

Gefällt dir das Wort "Arbeitsablauf" besser? Du kannst dich ja mal in die Vorteile der dezentralen / verteilten Versionsverwaltung einlesen.

Nebenbei wurde git nicht entwickelt, um irgendwas anders zu machen, um es anders zu machen, sondern entstand aus der Not heraus, da BitKeeper (ebenso ein dezentrales CVS) den kostenlosen Client eingestellt hat. Damals hat sogar SVN gesagt, dass SVN zur Kernel-Entwicklung nicht geeignet sei: http://subversion.tigris.org/subversion-linus.html
 
Rundherum Linux und Git Entwicklung als "Chaoshaufen" zu bezeichnen ist keine Kritik?

Das ist nur ins Preußische übersetzt. Wir in Bayern sprechen da liebevoll von einem "Sauhaufen" (wir mögen Schweinshaxn).

Und es scheint ja einen Haufen Leute zu geben, die genau das mögen - wer wäre ich also, das zu kritisieren? Mir bleibt nur, festzustellen, dass das für die Zwecke, für die ich ein Unix brauche, unbrauchbar ist.

Was ist denn dein Problem mit git? Du hast zwar viel geschrieben, aber da war leider keinerlei "technisch-fachliche Bewertungen" dabei.

Inwiefern ist der Sachverhalt, dass man Dinge nicht on-the-fly fixen kann, wenn man die exakten Sourcen nicht griffbereit hat, Dir nicht technisch-fachlich genug?

Im Berkeley, konkret FreeBSD, brauche ich nur die Nummer, die mir "uname" ausgibt, auf https://svnweb.freebsd.org/ einzugeben, und kriege die genaue Herkunftsgeschichte, in toto.
Mit git geht das sicher irgendwie auch, aber bei dem guten dutzend Ports, wo ich die Herkunft der enthaltenen Bugs ermitteln hätte müssen, und dafür auf eine github-Seite verwiesen wurde, ist es mir meist nicht gelungen - ich konnte da nichtmal Hinweise auf jene Version finden, mit der der Port gelabelt ist. Stattdessen kam ich mir vor wie ein Archäologe bei der Ausgrabung.

Gefällt dir das Wort "Arbeitsablauf" besser?

Mir geht es nicht um das Wort (obgleich es einen Arbeitsablauf zugegeben nicht vereinfacht, wenn man ihn Workflow nennt), sondern darum, was -im groben- Du darunter verstehst, in Zusammenhang mit git.

Du kannst dich ja mal in die Vorteile der dezentralen / verteilten Versionsverwaltung einlesen.

Ach ja? Ich denke mal, nach 25 Jahren IT-Infrastruktur-Beratung, insbesondere für Versicherungen, TelCos, Großbanken und Healthcare-Unternehmen, hab ich schon ein klein bischen praktische Erfahrung in der Sache.

Damals hat sogar SVN gesagt, dass SVN zur Kernel-Entwicklung nicht geeignet sei: http://subversion.tigris.org/subversion-linus.html

Das stimmt nicht. In dem verlinkten Artikel steht, dass SVN für den Linux-Kernel und die Arbeitsweise des Linux-Teams nicht geeignet ist. Und das ist exakt das, was ich oben auch schon schrieb: git ist entwickelt worden, um genau diese Arbeitsweise zu unterstützen.

Deswegen ist die m.E. entscheidende Frage, ob wir diese Art der Arbeitsweise haben wollen (und welche Konsequenzen das hat). Und deswegen hab ich gefragt, was Du diesbezüglich unter der Arbeitsweise verstehst.

Dazu kommt: die haben einen Kernel. Den Rest wälzen sie ab auf einen Distributor. Ein Kernel nützt mich aber nichts, und ein Distributor, der dann u.U. einen, ja, Sauhaufen zusammenstellt, ist mir auch nicht hilfreich. Vor allem aber: diese Zusammenstellung ist da typischerweise nicht im Repo - die ist überhaupt nicht rückverfolgbar.
Damit wird das Repo zu einer reinen Spielwiese der Entwickler. Das ist aber bei Berkeley nicht so: wir haben die volle Rückverfolgbarkeit von allem (fast bis Net/2, und ggfs. einschliesslich der Ports bis zur Integration).
Das ist eine völlig andere Qualität, und für mich ist es das entscheidende Qualitätsmerkmal. Ja, ich bin da banken-verwöhnt: alles muß 100%ig transparent dokumentiert sein. Nur dass es die Banken mit einem Übermaß an Verwaltung realisieren, während es hier einfach SVN tut.
 
Mit git geht das sicher irgendwie auch, aber bei dem guten dutzend Ports, wo ich die Herkunft der enthaltenen Bugs ermitteln hätte müssen, und dafür auf eine github-Seite verwiesen wurde, ist es mir meist nicht gelungen - ich konnte da nichtmal Hinweise auf jene Version finden, mit der der Port gelabelt ist. Stattdessen kam ich mir vor wie ein Archäologe bei der Ausgrabung.

Um mal beim technischen zu bleiben... Der Rest von dir ist leider nur unfundierte Meinung auf die ich schlecht eingehen kann. Aber wo genau hattest du jetzt in dem Fall ein Problem? Es ist doch vollkommen egal wie eine entsprechende Version zustande gekommen ist, in der Regel hat ein Projekt nur ein Repository aus dem dann für den Endnutzer die Binärversion erstellt wird (dem Master-Branch). Da geht auch keinerlei Historie verloren und ist ausgehend von einem Commit-Hash immer lückenlos rückverfolgbar. Denn bei einem Merge von einem Branch wird auch die komplette Historie mit "gemerged", vollkommen egal woher der Branch kommt.

Nimm's mir nicht übel, aber du schreibst hier teils einfach Sachen die schlicht und ergreifend nicht stimmen.
 
Um mal beim technischen zu bleiben... Der Rest von dir ist leider nur unfundierte Meinung auf die ich schlecht eingehen kann.

Kannst Du etwas davon aufzeigen, was angeblich nicht fundiert sei? Oder findest Du Technikfolgenbewertung, Arbeitskultur und die ganzen Soft-Skills lediglich unbedeutend?

Aber wo genau hattest du jetzt in dem Fall ein Problem? Es ist doch vollkommen egal wie eine entsprechende Version zustande gekommen ist,

Es ist ganz und gar nicht egal, sondern es ist notwendig um den Code zu verstehen (sofern man das will). Aber wie schon gesagt, die Auffassung scheint da zu sein: der User braucht das eh nicht verstehen, da sind die Entwickler unter sich.

Nur eben: dafür habe ich kein Verständnis. Ich habe ungefähr tausend Ports installiert, und ich bin weder imstande noch gewillt, all deren Entwicklungsgeschichten mitzuverfolgen. Wenn also einer dieser Ports nicht das tut, was er soll, dann -und erst dann- schaue ich in die Source. Da sehe ich dann -wahrscheinlich-, was falsch läuft. Im nächsten Schritt gilt es dann herauszufinden, wann und wie dieses Problem enstanden ist und/oder ob es vielleicht in einer neueren Version behoben ist. Dazu braucht es den Zugriff auf ein VCS, und zwar von dem Punkt ausgehend, der eben diese entsprechende Version darstellt.

Da geht auch keinerlei Historie verloren und ist ausgehend von einem Commit-Hash immer lückenlos rückverfolgbar. Denn bei einem Merge von einem Branch wird auch die komplette Historie mit "gemerged", vollkommen egal woher der Branch kommt.

Das weiß ich selber. Aber wenn ich nach /usr/ports/x/y gehe und "make extract" sage, dann habe ich dadurch noch keinen "Commit-Hash", sondern eine Versionsnummer. Und dann geht die Sucherei und Herumklickerei los. Das ist bestimmt alles irgendwie lösbar, aber verwirrend und verwickelt und fast so gräßlich als wollte man Facebook nutzen.

Nimm's mir nicht übel, aber du schreibst hier teils einfach Sachen die schlicht und ergreifend nicht stimmen.

Konkret? Dir geht es offenbar um den Arbeitsstil von git, weil Dir der gefällt. Nur, dann solltest Du anderen auch zugestehen, dass sie ihre eigenen Vorstellungen von Arbeitsstil haben, die mitunter aus einem langen Reifungsprozess hervorgegangen sind. Das heisst nicht, dass man diese Vorstellungen nicht ändern kann - aber dafür sollte man dann gute Gründe haben.
Dass "alle es machen" war noch nie ein guter Grund - ausser an der Börse, und auch da nur, wenn man zu den ersten gehört.
 
Gerade eben hast du noch behauptet bei git würde die Historie und die lückenlose Verfolgbarkeit nicht gegeben sein und plötzlich sagst du, du wüsstest selbst, dass das alles bei git doch geht?

Trotz deiner Forderung nach einer "technisch-fachliche Bewertungen" hast du selbst bisher nichts in die Richtung getan. Bis auf komplett unfundierte "alles Chaos", "alles Sauhaufen" Aussagen und Ausschweifungen die mit einem VCS so absolut nichts zu tun haben, kam von dir leider nichts. Stattdessen argumentierst du auf einer "Mein Haus, mein Auto, mein Boot" Ebene, als wenn mich das in irgend einer Form einschüchtern soll. Kratzt mich nur nicht, deine Aussagen stimmen trotzdem hinten und vorne nicht.

Abseits davon, dass die Unterhaltung eh schon in der Mülltonne ist, hab ich auch keine Lust an einer Diskussion bei der du ständig deine getätigten Aussagen drehst wie dir sie gerade passen und Aussagen vom letzten Beitrag plötzlich nicht mehr gelten.
 
Zurück
Oben