Deep Dive 192 –

Jujutsu mit Daniel Danner

30.09.2025

// Podcast
// Deep Dive 192

Shownotes

Schon in Folge 20/25 haben wir über Jujutsu gesprochen, die Git-Alternative von Google, die auf der CLI jj genannt wird. Diesmal gehen wir tiefer. Wir fragen, wie Jujutsu Merge-Konflikte zu First-Class-Citizens macht und schauen uns an, wie es ohne klassische Branches funktioniert. Was steckt hinter Features wie Mega-Merges?

Für ein besseres Verständnis von jj haben wir Daniel Danner eingeladen. Er ist erfahrener Jujutsu-Nutzer und beleuchtet die fundamentalen Unterschiede zu Git. Wir besprechen die grundlegende Architektur und praktische Nutzung auf der Konsole. Daniel zeigt außerdem, wie Jujutsu dank seiner Modularisierung kompatibel zu Git bleibt und sich in bestehende Workflows integrieren lässt.

Jan und Dave diskutieren mit Daniel auch mögliche Nachteile und Inkompatibilitäten. Etwa, wenn sich die gesamte Historie bearbeiten lässt oder Merge-Konflikte sich auf einmal breiter verteilen. Und wer bis zum Ende zuhört, erfährt, welche geheime Karriere Dave neben der programmier.bar noch verfolgt. ;)

Download

/transkript/programmierbar/deep-dive-192-jujutsu-mit-daniel-danner

Jan: Hallo und herzlich willkommen zu 1 neuen Deep Dive Folge hier in der programmier.bar und heute hier mit mir am Start ist der Dave. Moin Dave.
Daniel: Oh ja, hallo.
Jan: Du bist heute in meiner oberen Ecke hier im virtuellen Studio, weil irgendwie Riverside heute entschieden hat, alles vertikal anzuordnen. Wir wollen heute über ein Thema sprechen, das wir schon mal in der Programmierer hatten, nämlich in der Folge. Dave, weiß es noch?
Dave: 22. Woche 22. War das war das
Jan: dann geraten oder hast Du dich vorbereitet? Das war oh, das war geraten. Ja, aber es war leider
Daniel: falsch. Ja,
Jan: genau. Aber erschrecken nah dran. Also es war nämlich 20, 25. 20. Ja, okay. Ja, jetzt Da haben wir in 1 News Folge über ein Tool gesprochen, das Jojitsu heißt, abgekürzt JJ, so wie auch der CIA Befehl dafür ist und das schickt sich an eine eine Git Alternative zu werden. Und da haben wir gesagt, na ja, es liest sich konzeptionell irgendwie ganz cool und hat auch son paar coole Vorteile und unser Fazit war so, es wär voll cool, wenn das mal Leute benutzen würden und son bisschen Erfahrung damit sammeln würden, damit wir mal sehen würden, ob das was taugt. Und dann war ich im Juli auf der Socrates Konferenz. Die Socrates Konferenz ist ja son großes großes UnKonference Ding, ich glaub mit das Größte so auch in in Deutschland, in dem Softwarecraft Bereich und da hat tatsächlich sich jemand gemeldet und sagt so hey, ich benutze hier dieses Tool JJ, das ist viel cooler als geht und ich mach mal eine Session darüber und erzähl euch, was was das hier alles kann und warum das viel toller ist. So, okay, da geh ich mal hin und hör mir das mal an im Detail. Und das war von dem Daniel. Der Daniel hat da die Session gemacht und hat uns eine Stunde lang erzählt, warum das alles cool ist. Und danach war ich ja quasi schon fast überzeugt. Und dann hab ich gedacht, okay, wenn das so cool war, dann laden wir den Daniel mal hier in den Podcast ein und dann kann er hier mal das das gute Jujitsu Word spreden sozusagen an die Community. Und dementsprechend, hallo Daniel, schön, dass Du da bist. Hallo. Hey. Daniel, ich hab eben grad schon gesagt, wir haben uns auf der Sokka Test kennengelernt, aber vielleicht willst Du einmal kurz erzählen, wer Du bist und was Du machst, wenn Du nicht auf irgendwelchen Barcamps rumhängst.
Daniel: Ja gerne. Ja also mein Name ist Daniel, ich bin Softwareentwickler bei InnoVix. Ich mach das jetzt hier im Dienstleistungsgeschäft seit ungefähr 10 Jahren, hab in Erlangenem Format studiert. Ich hüpfe viel auf unconferences rum, aber doch die meiste Zeit mache ich tatsächlich klassische Softwareentwicklungen. Die letzten 2 Jahre dot net c sharp im Industrial Sensorbereich. Und ja, ein Thema, was mich da jetzt eigentlich schon von Anfang an immer begleitet, ist, wie kontrollier ich meine Versionen? Also ist eine gewisse Leidenschaft für mich, meine Versionen zu kontrollieren, daher hat JJ bei mir auch offene Türen eingerannt.
Jan: Jetzt klingt ja so dieser Bereich, also ich stell mir das bei euch so Consulting als Dienstleister für große Dritte vor, ja? In und Wechsel ist jetzt ja auch kein kleiner Laden, ne? Also habt ihr wahrscheinlich eher mit Mittelständlern, größeren Unternehmen irgendwie zu tun. Stell ich mir jetzt nicht als so die klassische Spielwiese vor, wo man mal sagen könnte, ah, dieses Git, das funktioniert zwar, aber lass mal was ganz anderes benutzen. So, wie wie bist Du denn zu zu JJ gekommen? Wie ist das überhaupt auf deinem Radar gelandet?
Daniel: Also ja, in der Tat ist das immer eine Hürde in der in der Realität, irgendwie neue Tools also sich einzusetzen. Und ich hab vor ungefähr 2 Jahren vielleicht das erste Mal so von JJ gehört, hätte mich nicht genau damit auseinandergesetzt, nur quasi zu die Überschrift auf Hacker News oder irgendwie so was. Ich weiß es nicht mehr genau. Und hatte mir quasi nur so das gedachte Prospekt angeschaut und gelesen, ah ja, Git Alternative, mhm. Und gelesen, es ist kompatibel mit Git. Ich kann das also verwenden, in einem Projekt, in dem eigentlich Git und irgendeine forge, GitLab oder GitHub verwendet wird, dort mitzuarbeiten und andere müssen nicht mitmachen. Dachte ich so, ja, anders geht's eigentlich nicht. Das ist die einzige Voraussetzung, wie eigentlich eine Git Alternative eine Chance hat, diesen Graben von Git zu überwinden, indem sie diese Kompatibilität herstellt. Seitdem ich das so im Hinterkopf, dass ich mich mal Zeit hab, schaue ich mir das mal in Ruhe an. War aber auch eigentlich viel zu zufrieden mit Git und hatte auch das Gefühl, ich ich kann das eigentlich gut. Ich verstehe, warum viele Leute keine Riesenfans sind und die UX kritisieren. Das ist sehr kompliziert ist und so weiter. Aber ich hatte nie son persönlichen Beef damit, weil ich dachte, ich mach das lang genug und ich kann das. Und deswegen hat es 2 Jahre gedauert, bis ich mir noch mal angeschaut hab. Aber dann war ich, ich glaub, im Mai war das, auf der Sokrates Gran Canaria. Und hatte dort ein bisschen Zeit zwischen den Sessions und dachte, die nutze ich jetzt. Ich schau's mir jetzt mal an. Und dann hat's noch so 2 Wochen gedauert und dann hab ich das produktiv von meinem Projekt verwendet. Ich glaub, meine Teamkollegen wissen das jetzt noch gar nicht. Ich wollt's denen gar nicht so auf die Nase binden, nicht dass dann ihnen irgendwas auffällt, was komisch ist, bevor ich's selber fixen kann. Aber ich benutz es jetzt einfach. Und ich werd dann auch vielleicht mal andere Leute motivieren, das mitzubenutzen. Aber erste Linie war jetzt so mein Antrieb, es löst jetzt mein Problem. Und ich werd das son bisschen Erfahrungen sammeln und auch 'n bisschen überlegen, ob ich's tatsächlich jetzt jedem empfehlen würde, weil es ist schon auch noch experimentell, muss man sagen. Aber für mich ist es jetzt produktive Softwareentwicklungs Tool, Unterstützung für mich.
Jan: Vielleicht machen wir da noch mal 'n halben Schritt zurück, ne. Du hast eben gesagt, na, Du hast eigentlich gar keinen Beef so mit Git. Dave, hast Du Beef mit Git?
Dave: Also das Ding ist, das waren also wär auch die, das ist eigentlich mal eine Einstiegsfrage gewesen son bisschen, ne. Also weil eigentlich denk ich mir so, ich bin sehr zufrieden mit Git und es ist nicht irgendetwas da, wo ich sage, oh, das Hemd nicht wirklich sehr krass oder mein mein Workflow ist superviel schlechter irgendwie mit Git oder das wird das jetzt extrem verbessern. Hab 'n bisschen drüber nachgedacht und hab sogar eine Sache, aber da würd ich irgendwie später drauf eingehen. Deswegen eigentlich per se, ich hab kein Problem mit Git, so muss ich ehrlicherweise sagen.
Jan: Jetzt date ich mich hier vielleicht son son bisschen selbst, aber als ich so angefangen hab mit Softwareentwicklung und in das erste größere Projekt irgendwie reingestolpert bin, war eine der ersten großen Architekturdiskussionen so, oh, sollen wir dieses Projekt, was zum damaligen Zeitpunkt schon irgendwie, ich weiß es nicht, 5 oder 10 Jahre alt war, sollen wir das mal von subversion auf Git migrieren. Geht das dieses neue heiße Tooling so, ja? Das benutzen jetzt die ganzen coolen Kinder und subversion macht uns ja irgendwie nur Probleme. Und auch da war gefühlt schon die Diskussion so, na ja eigentlich funktioniert ja Subversion und was kann denn jetzt irgendwie geht irgendwie mehr so, ja? Und da da musste ich son bisschen dran zurückdenken, als ich an diese JJ Diskussion dann dachte, dass ich so ja, aber mit was mit was lockt es mich denn, ja? Und im also im Nachhinein muss ich sagen, ich bin sehr froh, dass wir auf GDO umgestiegen sind und ich in meinem ganzen Entwicklerleben nur sehr kurz mit Subversion zu tun hatte so, ja.
Dave: Gut, ich frag mal das war das aber 'n aufwendige Migration quasi von Subversion auf Git? Also
Jan: Also die die Frage ist ja immer bei so was, wie viel Du mitnehmen willst, ne? Weil der einfachste Zug ist ja einfach, Du Du Du machst den Stand jetzt und checkst den in neues Git Repositoryial. Ja, ja. So und dann hängt das eher daran, wie schaffst Du es, die ganze History sauber mitzunehmen?
Dave: Mhm.
Daniel: Wie
Jan: schaffst Du es irgendwie, alle Branches, die es grade gibt, irgendwie so mitzunehmen? Wie machst Du eine eine User Zuordnung, dass das halt irgendwie, also das war mehr so
Daniel: Mhm.
Jan: Der der der der Pain Point so, ne. Aber aber im Prinzip, wie gesagt, war rückblickend irgendwie sehr froh und vielleicht ist es dann bei bei Jayja halt im Prinzip auch so, ja, dass sich die der der große Vorteil gar nicht zwangsläufig aus dem direkten 1 zu 1 Vergleich jetzt auf auf dem Papier irgendwie ergeben muss, sondern dann eher man vielleicht so nach Benutzung son bisschen drauf guckt, nennt sich ja, schon gut, dass man das gemacht hat, weil der Vorteil sich eigentlich viel mehr im Alltag so widerspiegelt als in irgend 'nem Feature Vergleich pro Contra oder so was, ja. Daniel, als der einzige von uns, der jetzt tatsächlich Erfahrung hat so mit mit J. J. Würdest Du dem so so zustimmen, Du benutzt es jetzt schon zumindest 'n paar Monate quasi, Was ist so dein gefühltes erstes Fazit? Ohne zu tief einzusteigen, weil wir müssen gleich auch noch mal vielleicht kurz abreißen, was also ne, was überhaupt der große Unterschied ist. Aber was ist so dein erstes Fazit?
Daniel: Also okay, ich versuch nichts, dich wahr zu steigen. Es ist eine vielschichtige Frage, weil ich glaube, es berührt 2 orthogonale Sachen. Das eine ist der Mehrwert von JJ dafür, wie ich's jetzt benutze und das ist quasi als Client für ein GIT Projekt, was niemand anderen betrifft im Projekt. Das andere ist die Abstraktionen, die JJ mitbringt, die eigentlich die Grundlage bilden würden für viel bessere Forges, als wir sie jetzt haben. Und ich glaube, der Moment, wo man als, also wir als Community oder Industrie sagen würden, ja, Goodwillens, zum Glück verwenden wir jetzt alle JJ und das ist eine gewisse utopische Vorstellung, die ich vielleicht mit mir rumtrage, würde glaube ich eher darauf basieren in dem Moment, wo JJ als Konzept eben auch auftaucht in den Forgees, in denen wir kooperieren. Und für den End User ist es, muss man schon auch zugeben, also ich hab ich hab nicht viele andere Alternativen evaluiert in meiner Laufbahn. Ich war schon immer recht zufrieden damit. Aber ich hab schon gehört, es gibt schon andere Sachen, Git Butler, Margit oder so was. Gibt's verschiedene Sachen, die auch sagen, ich gebe dir vereinfachende Abstraktionen auf deinem Client. Den Rest ist das egal und das macht dein Leben 'n bisschen leichter und Du musst dich nicht mit diesem etwas kantigen Tool auf der auseinandersetzen. Alles ist cool. Man könnte schon sagen, JJ ist auch nicht mehr als das, so wie ich's jetzt benutze. Aber ich finde, im Laufe der nächsten Stunde werd ich schon argumentieren, inwiefern das eben das schon ist. Mhm.
Jan: Okay, dann bevor wir zu tief in diese Argumentation einsteigen, vielleicht schaffen wir es so den 30 bis 60 Sekunden Elevator Pitch zu finden für, was ist eigentlich JJ und was will das so prinzipiell anders machen als Git?
Daniel: Okay, ich versuch's. Ich hab keinen vorbereitet. Was ist Zeit neu? 30 bis 60 Sekunden.
Dave: Oh, nur noch anderthalb Sekunden.
Daniel: Ich würde sagen, es ist eine mächtigere Abstraktion oberhalb von Git, ist, sondern eben tatsächlich eine, also man kann mehr machen damit, als man mit machen kann, ohne dass man mehr Komplexität hat für die man, da man bezahlen muss. Und eliminiert damit auch viele Dinge, die in Gitch Schmerzen bereiten im Kontext von, in dem es sich davon verabschiedet. Man muss es sich mehr so vorstellen wie eine Hochsprache gegenüber c oder. Es ist quasi eine Abstraktion, die mächtiger ist. Man will eigentlich nicht mehr runtergehen, wenn man mal oben war.
Dave: Muss man muss.
Jan: Und weil Du jetzt gesagt hast, oberhalb von Git, damit reden wir quasi hierarchisch, abstrakt von Git, und nicht, so mein Verständnis, aufbauend auf Git. Du hast zwar gesagt und das ist Git kompatibel, so man kann es in diesem Modus betreiben, aber es nutzt nicht zwangsläufig geht unter der Haube, nur das klarzustellen.
Daniel: Exakt, ja, das ist also eine diffizielle Unterscheidung tatsächlich. Es ist genau wie Du es gesagt hast, also in der Praxis benutzt es jetzt geht unter der Haube, schlichtweg weil Git im Grunde eine gut geeignete für ein mächtigeres Versionskontrollsystem ist, was genau ist, was wir hier haben. Es gibt wenig Gründe, das neu zu schreiben, weil es funktioniert einfach, aber es ist mehr so wie 'n Dateisystem fürn Programm, ist halt Git eine für JJ. In der Implementierung von JJ ist vorgesehen, dass es auch eine eine unter der Haube hat, die JJ spezifisch ist und damit sozusagen gewisse Dinge von g eben nicht mit sich rumschleppen muss. Aber aus Gründen der Praktikabilität benutzt es eben jetzt einfach. Das heißt, wir haben im Grunde 2 Stellen, wo wir auf aufbauen in JG. Das eine ist eben die konkrete Informierung. Also man hat lokal, wenn man JG benutzt, immer unter der Haube ein Gitrepositorium, mit dem kann man auch interagieren, wenn man möchte. Und die andere Kompatibilität ist, dass man natürlich auch mit einem Server reden kann, also Push und Pull. Das würde jetzt an sich nicht voraussetzen, dass eine Zeile auf meinem Rechner läuft. Aber faktisch in der Praxis ist es so, das stört aber nicht und erlaubt einen zwar durch diese Abstraktion durchzubrechen, aber man man muss eigentlich an keiner Stelle.
Jan: Und ist das ein Provisorium oder ist das so bei Design? Du hast es schon gesagt, ne, architektonisch werden da andere Storage Engines quasi möglich. Und ist das ein erklärtes Ziel von JJ zu sagen, okay, irgendwann emanzipiert man sich von Git und ist da nicht mehr drauf angewiesen und hat vielleicht eine eigene Engine, die schneller, effizienter, anders wie auch immer arbeitet oder sieht man das gar nicht so als großes Problem, Aufhänger, wie auch immer und sagt hat, na ja, dann dann bleiben wir halt auf Git, so, ne. Und machen halt nur oben drüber noch mehr.
Daniel: Ist eine gute Frage. Ich bin mir gar nicht so sicher, ehrlich gesagt. Der Eindruck, den ich bekommen hab, ist, dass man eben schon sich an irgend 'nem Punkt freimachen will davon, aber auch gleichzeitig, glaube ich, sich auf eine Weise abdreht von Git, dass man sagt, das ist jetzt auch nicht wesentlich, dass man das schafft. Weil anders als jetzt andere Situationen, wo irgendwie historische Software, neue Software ablösen soll, gibt ja keinen Grund, Git loszuwerden. Man will nur das nicht mehr benutzen müssen. Aber es es dürfte da schon als für immer verweilen. Und wenn man mich fragt, ich denke, die Intention hinter der jiddish spezifischen Storage Engine ist auch, sich selber zu beweisen, dass man nicht auf Spezifika dependet auf irgendeine Art und Weise. Also dass es auch ohne Dinge funktioniert. Ich hab selber gar nicht ausprobiert, wie's ohne Git ausschaut, ob's überhaupt funktioniert. Ich glaub, es ist, übersteht nur ja experimentell macht man jetzt so nicht, ne, aber also nicht produktiv. Es gibt schon Stellen, wo man in der JJ Oberfläche Git Commit IDs zum Beispiel sieht und sehen kann und auch mit ihnen interagieren kann. Man muss zählst, aber man kann sie dort sehen. Und es gibt 'n paar Zugeständnisse in JJ, die dem gerecht werden, was ich eigentlich ein ganz ulkiges Detail fand, dass zum Beispiel Change IDs in JJ sind ähnlich wie Git Committe IDs, aber sie benutzen einfach genau den Rest des Sets. Also sind halt a bis f 0 bis 9. Und JJ benutzt genau den Rest und dadurch kann man diese IDs immer von den anderen unterscheiden. Das heißt, da ist es jetzt schon, weil JJ ist so, weil die gibt's so ist. Und im Log sieht man dann eben auch beide IDs. Man kann also sehen, was ist der JJay Change? Was ist der drunterliegende Git Commit? Und ich vermute, wenn man sich von Gilt freimacht, würde man das da nicht mehr sehen, weil warum auch? Kein Grund, damit konfrontiert zu werden.
Jan: Okay, jetzt hast Du grade schon den ersten konkreten Unterschied angesprochen, ne. In dem einen heißt das Change ID, in dem anderen heißt das Commid ID oder Commid Hash ja auch, ne. Mhm. Ist das jetzt nur Nomenklatur oder was ist denn so der der große Unterschied in der Benutzung? Ja,
Daniel: das ist schon wesentlich jetzt. Jetzt können wir einsteigen,
Dave: Frau, let's go.
Daniel: Ja, also ich würde, wenn ich versuche, Jayje zu erklären, beginne ich immer mit eigentlich 2 wesentlichen Unterschieden, aus denen dann eigentlich alle folgen. Also alles, was jetzt dann großartig an JaJJS folgt eigentlich aus diesen 2 Designentscheidungen in JaJJ. Und das ist die eine davon, was das genauste jetzt angesprochen hast, ist, JJ hat ein Konzept von Changes, deren Identität nicht in ihrem Inhalt begründet ist, sondern in ihrer Semantik. Da muss man jetzt erklären, euch was ich damit meine. In Git ist es ganz klar, also wer jetzt kennt, weiß, Commid ids sind ein Hash des Changes oder eigentlich der Historie, wie wir da hingekommen sind. Das heißt, die ID 1 Commits repräsentiert immer exakt technisch, was dieser Commit macht und worauf er aufsitzt und ändert sich deswegen auch die ganze Zeit, wenn man was daran ändert, wenn man ein Rebase macht oder eine Band macht, kriegt man eine neue Committe ID. Was man in geht nicht ohne Weiteres hat, ist eine Vorstellung davon, dass auch nachdem ich's am Ende hab, sagen wir ein Typo in der Committe Message zu ändern, zu fixen, ist es immer noch derselbe Change. Also semantisch ist immer noch dasselbe, was ich vorher tun wollte. Ich hab nur den Inhalt des geändert. Das heißt, ich hab eigentlich eine Änderung an der Änderung gemacht und diese Mitverfolgung in Git muss ich quasi selber machen. Ich muss sagen, das erkenne ich wieder. Das ist ja die Message wie früher. Ich ich ich muss das als User wissen, weil technisch hab ich jetzt plötzlich 2 Commets. 1 1 der alte, eine ist der Neue. Je nachdem, was ich bei rebases mache, sehe ich in meiner Historie vielleicht auch beide und muss dann vielleicht die Datum anschauen, zu beurteilen, was davon ist eigentlich der neuere? Hätte ich da vielleicht müssen oder so was? Diesen Überblick muss ich behalten als User aufgrund dessen, wie das macht. Und das ist ja jetzt für Git, das will ich gar nicht kritisieren, eine sehr schlaue Idee und eine enorme Verbesserung gegenüber dem, was wir vorher hatten, also in SVN Zeiten. Aber für die Softwareentwicklung eigentlich fühlt sich's zu roh an, weil ich dann letztlich eben doch oft wissen will, was ich eigentlich mache und wie ich da hingekommen bin. Wir kriegen so was dann oft indirekt. Wir machen zum Beispiel auf in und sagen, ja, das ist jetzt die semantische Änderung und dann kann ich auf den kann ich dann pushen und dann änder ich die Änderung, bis sie fertig ist. Das heißt, man könnte sagen ID ist vielleicht son bisschen das, was wir hier vermissen. Ich weiß nicht, habt ihr mal Garrett verwendet? Das sage ich immer so. Nein.
Dave: Das macht mir gar nichts mehr.
Daniel: Jan auch nicht?
Dave: Gar keine Reaktion.
Daniel: Aus Flashbacks.
Dave: Ja, genau. Kriegsflashback.
Jan: Ja, auch Traummaßen. Ja, Schweißausbrüche. Angst in den Augen.
Dave: Er verlässt sofort den Raum.
Jan: Nicht nicht nicht viel. So, ich kenn es, aber ich hab's, ich muss das nie benutzen.
Daniel: Immerhin, weil es ist für mich immer ganz erstaunlich, weil ich sehr oft in solchen Gesprächen eben auf Garet verweise, weil aus irgend 'nem Grund bin ich irgendwie in 1 Bubble aufgewachsen, in der Garet irgendwie präsent war, obwohl es ja nie wirklich den Popularity Contest nur ansatzweise gewonnen hat. Und es wundert mich immer, weil es so vieles in Gerrit so viel besser war als in allen anderen Tools. Und ich hätte mir so sehr gewünscht, dass das erfolgreich ist als der Rest.
Jan: Das musst Du jetzt auch einmal erklären, glaube ich, weil viele da draußen das vielleicht auch nicht kennen können.
Daniel: Ja, ich will gar nicht unbedingt Gerrit erklären, ehrlich gesagt, weil ich erklär lieber, warum alles andere schlecht ist, als warum Geld gut ist, weil es hat spielt keine Rolle. Niemand wird praktisch mehr realistischer Okay. Verwendet. Das ist das ist keine tote Software, aber ich werd kein Geld Pitch machen. Das hat hab ich oft genug probiert, das hat keinen Sinn. Aber eine wesentliche Eigenschaft, die Gerhard eben mitbringt, ist, SSS quasi bastelt diese semantische Identität von Changes mit rein, indem es einfach eine Change ID mit in die Message schreibt. Und damit kann man immer, auch wenn man den Committe geändert hat und damit eine neue ID hat, kann Garet wiedererkennen, ah, das ist dasselbe Ding, ja. Es ist 'n bisschen wie, als würde man jetzt Github verwenden und man würde die Pury Quest ID, wenn man sie denn schon weiß, irgendwie in die Committe Message mit reinpacken, die man da hat als einzigen Committe auf der Brand. Und und damit immer wieder erkennen, wozu das gehört. So. Fragt man sich jetzt aber als als als Gitaböser, was was würde mir das bringen? Aber Gerhard zieht da viele Vorteile raus, die und macht es damit als sehr ähnlich zu dem, was uns JJ bietet. Und ich dachte tatsächlich, als ich vorher mir JJ angeschaut hab, dass JJ das auch so macht, dass es auch eine, sorry eine Change ID in die mit reinschreibt, das nachzufragen. Tut's aber tatsächlich nicht. Es ist ein bisschen sneakia. Es schreibt es als Metadatum in die Objekte im in get rein. Man sieht das nicht. Man muss da sehr gezielt da noch suchen. Mhm. Aber dann sieht man das. Und daran erkennt das die Sachen wieder. Diese Metadaten gehen aber auch teilweise verloren. Also wenn man jetzt zum Beispiel in GitLab auf den Button drückt, dann bleibt das da. Aber wenn, ich glaub, wenn jemand lokal eine macht und wieder pusht, dann gehen diese Sachen oft verloren, weil geht das halt nicht kennt. Aber das ist jetzt Aber jetzt
Jan: muss ich sagen, das ist so das Ende meines Verständnisses, was wir jetzt son bisschen erreicht haben. Also ich kenn so den den Blob Storage und so was alles, ja. So, da da komm ich noch mit. Aber wenn Du das heißt, da hängen so Metainformationen dran. Ist das was, was ich als Git Client quasi beliebig erweitern kann und was sich dann einfach JJ so zu nutzen macht?
Daniel: Hat mich auch überrascht, aber anscheinend ja. Also. Okay. Man kann, ich glaub, es scat cat minus File oder so heißt der Command. Also ich bin da 'n bisschen eingerostet, was die Strukturen da angeht. Und da kann man das Objekt quasi sich roh zeigen lassen und dann bekommt man einfach sone Datei, da steht im Wesentlichen die ID von dem tree Objekt, glaub ich, drin. Also der Snapshot, den der sich referenziert, die ID vom. Vielleicht noch das Datum und dann kommt, glaub ich, schon die Message. Und da, wo eben so die die oder die steht, da steht dann auch die JJ JJD. Aber also völlig irrelevant für JJ Benutzer muss man nie sehen. Mich hat's nur interessiert, wo's herkommt. Da kommt's her.
Jan: Okay. Okay. Und das war jetzt son bisschen der der strukturelle Unterschied so zwischen JJ und klassischem Git. Was für Unterschiede ergeben sich dann daraus für dich in der Benutzung?
Daniel: Genau. Ich ich würde vielleicht noch kurz den den zweiten Aspekt kurz erwähnen. Mhm. Weil das sind dann nämlich die 2 Sachen, an denen sozusagen alles hängt. Das Baumel Visum Baum an diesen 2 Features, die wir haben. Und weil's auch 'n bisschen unintuitiv und überraschend ist, denke ich, ist das da fang ich lieber bei bei an, weil das kennt man ja ganz gut, ne. Wir haben in eigentlich 3 Stellen, wo wir irgendwie Zustand in in. Das das eine sind. Also wir haben in der Historie und das sind Snapshots unser. Wir haben einen wohl definierten Zwischen, der sich nicht ändern kann, ne, weil die sind ja im Youtube. Das andere ist die Staging Area, die eigentlich auch wie 'n Committe ist, aber es gibt immer genau eine so. Und das ist quasi aber auch ein ein genau so ein Snapshot 1 Repositories Und das Dritte ist die Working Copy selbst. Also so, wie die Dateien eben da rumliegen, ist auch ein Zustand. Für das für den letzten Teil interessiert sich geht quasi gar nicht. So, die die liegen halt darum. Ich ich änder die, wenn man von einem auf den anderen wechselt oder so Sachen, aber ansonsten das ist eben das alles nicht. Und JJ macht das einfach nicht. JJ kollabiert alle diese 3 Sachen zu einem und sagt, das gibt's nicht mehr. Was nicht heißt, dass man irgendwelche Features verliert, erst direkt zum Beispiel das Leuten erzählst oft immer, wie soll ich das dann machen? Weil ich mache so Sachen wie, ich ändere irgendwie ganz viel in meinem Code und dann überlege ich, das gehört in 3 verschiedenen Branches und dann wechsle ich auf die auf den einen Branch, committe da ein bisschen was, dann wechsle ich auf den anderen Branch, committe da und das heißt, ich ziehe meine Work and Copy so von Branch zu Branch, wenn ich das mache. Das kann ich alles gar nicht machen in JJ. Ist aber alles möglich, kommen kommen wir noch dazu. Also man kann die Workflows genauso umsetzen, wie man das gewohntes begeht. Aber der wesentliche Punkt ist, alle Zustände in einem in der JJ Working Copy sind immer gemanagt von JJ. Es gibt quasi nichts, was nicht in einem Change hinterlegt ist zu jedem beliebigen Zeitpunkt. Und das ermöglicht, wenn ich mal so den Spoilern, sowieso Sachen wie ein mächtige und Du Funktion. Man kann im Grunde alles, was man im JJ macht, kann man rückgängig machen. Und damit ist die sozusagen ganz tief weggesperrt. Und Git Footguns, also ich erinner mich noch die ersten Jahre von Gitma hat sich die ganze Zeit in Fuß geschossen. Es war vollkommen Standard, dass man sagt, ich lösch einfach alles und klon's noch mal neu und mach die Arbeit der letzten 2 Stunden von vorne, aber ich krieg's nicht recovered, ne. Und oft war die Ursache dafür, jetzt so nach nach Jahren, als ich das dann auch selber überwunden hatte und wusste mir selber zu helfen und auch schon sehr lange kein Bit Checkout mehr gelöscht hab, mir zu helfen, ist mir klar geworden, ein allermeistens ist das passiert, weil es zu komischen unerwarteten Diskrepanzen zwischen diesen 3 Bereichen in git kam, die immer dann seltsam werden, wenn Branches zum Beispiel Dateien löschen oder hinzufügen und das dann beim Wechseln zwischen den Branches zu komischen Verhaltensweisen führt. Also beispielsweise könnte man auf eine sein, eine neue Datei haben, die da noch nicht committed ist. Da liegt die so rum. Alles ist cool. Dann wechselt man auf eine, wo Datei mit diesem Namen aber existiert und zufälligerweise denselben Content hat. Und dann wechselt man wieder zurück, dann ist die Datei weg. Wo sie vorher antracked war, man würde meinen, ein Checkout von 'nem Branch und wieder zurück sollte eigentlich nichts ändern, ne? Ist aber nicht so. Er geht dann und sagt, ach so, ja, die hast Du auf dem Branch nicht, dann tue ich die weg, ne. Die ist dann nicht verloren verloren, aber man muss schon wissen, wo sie hin ist. Solche Dinge können einem nicht passieren, weil eben JJ die volle Kontrolle über die Working Copy übernimmt. So, das war jetzt der der zweite Aspekt. So, und da das sind jetzt die 2 Bäume, von denen wir frisch ernten, die uns als Benutzer glücklich machen, wenn wir Jadio benutzen. So, und das war das war jetzt deine eigentliche Frage, ne. Jetzt kurz, dass ich den Faden verliere.
Jan: Ja, alles
Daniel: gut. Was was bedeutet das jetzt für uns? Genau. Also noch mal zurück dann eben zu der zu dem Aspekt, dass J J sich mehr mit der semantischen Identität von Changes befasst als mit der mit der von. Das bedeutet, man müssen konkreter, ne. Es man modelliert Changes in JJ und es sieht alles sehr ähnlich aus wie. Die haben, die haben IDs, die sind baumartig angeordnet. Also es gibt Merges, es gibt alles, was man so, wenn wir son Log anschauen, sieht das genauso aus wie. Git. Natürlich schaut's ein bisschen anders aus, aber die Konzepte sind genau die gleichen. Und man kann die auch im Nachhinein ändern, kann man den Git ja auch. Ich kann ja auch eine Versionhistorie in Git haben und sagen, ich möchte jetzt den dritten Commitment von oben noch mal modifizieren, ne. Hab ich viele Möglichkeiten, ne. Mache ich 'n interaktiv Re Base mit 'nem Edit oder ich squash was rein, ne, indem ich die Reihenfolge verändern. Kann ich alles auch in machen. Der Unterschied ist, das Modifizieren dieser Changes in der Historie ist im Grunde nicht 'n Afterfort, dass ich quasi Sachen verändere, sondern es ist die zentrale Operation, die ich mache. Also ich kann jeden Change in meiner Historie in JayJ nehmen und sagen, den möchte ich bearbeiten. Kann möchte da hin wechseln, so wie das Repo da ist in diesem Zustand, möchte da was bearbeiten und dann gehe ich quasi wieder woanders hin. Und das Spannende ist dann, es wirkt sich sofort aus. Ich muss nicht einen machen, Commits neu zu erzeugen, die dann diesen neuen Change als Vorgänger haben. Und was das auch bedeutet, ist, was was mir auch erst nach 'ner Weile klar geworden ist, dass die Commit Historie in JJ, also der die AG, ne, der directed a sadly Graph, ja. Meistens ist ja eine gerade Linie, ne, aber nicht immer. Ich würde Ihnen eher beschreiben als eine Folge von Operationen. Also man macht den, man macht den und dabei entstehen Objekte in diesem Graphen. Und die bleiben dann auch so, außer man macht eben History Writing, während in JJ derselbe Graf eher ein. Also man sagt, so möchte ich, dass das ausschaut. Ich möchte, dass diese so eine Art Baum bilden. Und dann kann ich aber immer noch jeden Knoten in diesen Baum modifizieren und der Baum bleibt trotzdem, wie er ist. Und jede Veränderung wirkt sich sofort auf den ganzen Baum aus. Das heißt, ich modifiziere eigentlich den Baum. Ich bearbeite den Baum, anstatt dass ich sage, ich, ne. Sondern ich bearbeite diesen diesen Grafen eigentlich, indem ich da einzustellen, reingehe. Und das hat natürlich 'n paar Folgen. Man denkt sich jetzt erst, ja, wie geht das denn? Was was ist denn, wenn das jetzt nicht klappt? Weil wenn ich 'n mach, hab ich ja oft Konflikte, ne. Ist ja son klassischer Fall, ne. Mach 'n, versteh irgendwas, passt nicht ganz zusammen. Dann macht geht das richtige Ding beim Interactive Report, stopp. Hier hast Du jetzt, ich konnte diesen nächsten Commit nicht applyen, dann müssen wir jetzt innehalten und das reparieren. Diese Probleme gehen natürlich nicht weg, nur weil welche das jetzt anders macht. Konflikte existieren natürlich immer noch. Mhm. Aber Konflikte existieren auf eine viel schönere Art und Weise, haben wir schon gesagt als First Class Citizenes, ja. Die sind jetzt nämlich irgendwie nicht son unangenehmer Seiteneffekt von 'ner Operation wie in Git, weil Git ja wirklich sagt so, halt stopp, treten auf die Bremsen, es quietscht und sagen, wir können jetzt gar nichts mehr machen, muss jetzt hier den Konflikt auflösen, muss man auch sofort sagen, wie ich den auflöse. Erst dann können wir weitermachen. Und die einzige andere Option, die Du hast, ist eine und dann tun wir so, als hätten wir gar nichts gemacht. Und dann musst Du dir überlegen, ob Du das traust, das noch mal von vorne zu machen.
Jan: Das muss man ja eigentlich sagen, Mhm. Konflikte existieren ja in Git quasi gar nicht. Also ne, Du hast gesagt, so
Daniel: und JayJ sind
Jan: sie quasi First Class Citizen, aber Git kennt sie ja eigentlich nicht.
Daniel: Exakt, genau.
Jan: Weil Git kennt nur Zustände mit aufgelösten Konflikten. Mhm.
Daniel: Und wenn
Jan: es halt 'n Konflikt trifft, dann heißt das so, okay, jetzt hört ja alles auf und und Du als als Mensch, als als Anwender musst es ja quasi manuell beheben, weil geht halt eben genau kein Verständnis davon hat.
Daniel: Absolut richtig, genau. Also also nicht nur, dass sie ja quasi in Low Klasse, das sind ja überhaupt kein Cancilison in in in Git. Absolut richtig. Genau. Also ich frage, was macht JJ jetzt da? JJ sagt, wenn Du jetzt ein Commit in der Vergangenheit oder der Nachfolger hat modifizierst und das dann im Konflikt damit steht, was danach kommt, dann ist dieser Committe, der danach kommt eben in einem conflikten State. So, ich ich wollte den, sollte das vor allen Dingen, denkt sich, Ja, ja, haben wir ja nicht genau gewusst wie, da musst Du quasi noch mal entscheiden. Und das heißt, solange es ist, haben wir schon rot markiert dann im Terminal und kannst dann jederzeit in diesem Kommentar gehen, wenn Du möchtest und das Problem adressieren, aber Du musst das nicht jetzt machen. Und Du kannst alles tun, was Du jetzt gerade tust. Das ist nicht ein Stop the presses und bevor wir weitermachen, musst Du Konflikt auflösen, sondern da ist halt jetzt 'n Konflikt und kannst Du lösen. Den kannst Du auch lösen, indem Du zum Beispiel merkst, ah ja, das passt auch nicht zusammen. Lass mich diesen Einkommen mit woanders hinlagern, dann hat er nämlich keinen Konflikt mehr. Und jetzt als erfahrener User kann man sich ja auch sehr leicht vorstellen, was da unter der Haube passiert, ne. Er macht halt einfach fleißige unter der Haube und sagt halt, wenn ich beim einen Konflikt hab, sag ich ja, dann merke ich mir einfach, wie das vorher war. Sage, wir würden hier eigentlich diesen einen Commitment auf den anderen tun, aber das geht nicht. Also merken wir uns, dass wir das tun würden. Und wenn der User sagt, ich möchte jetzt den Konflikt auflösen, dann sagen wir halt okay, dann probieren wir mal diese beiden Sachen übereinander zu stapeln, zeigen dem User, was daran nicht passt. Wenn der User das dann repariert, dann sagen wir, ah, das ist jetzt dann der neue Committe, der mit den aufgelösten Konflikten. Und ist glaube ich auch sehr viel leichter vorstellbar, wenn man's mal verwendet. Ja, ist ein bisschen diesen Medienkonflikt hier, also mit mit Worten über Ja. Kontrolle zu reden, ist schwerer, als man denkt. Ja. Und was man vielleicht wissen sollte, ist, also First Class Citizen, Konflikte heißt jetzt nicht, dass das irgendwie Objekte sind, die man managen müsste oder irgendwie so was, sondern das heißt nur, Changes in JJ können in einem sein, bis man sie editiert, damit sie nicht mehr im State sind. Mehr ist es eigentlich gar nicht.
Jan: Jetzt hab ich 2 vielleicht kritische Fragen, ja?
Daniel: Ja, gerne.
Jan: Weil die letzten 2 Punkte, die Du so als Stärke von JJ herausgestellt hast, könnte ich auch umgedreht nicht als Defizit, sondern als Stärke von Giz sehen, ne. Der eine Punkt ist, diesen den Konflikt nicht als State in Git zu haben, macht es mir natürlich gerade beim verteilten Arbeiten deutlich leichter, weil natürlich auch keine Failstates propagieren, ja. Also das verhindert ja, ob gewollt oder ungewollt, aber de facto verhindert das ja, dass die Merge Konflikte das einen zum Problem von jemand anderem werden, weil sie eben resolved werden müssen, bevor dieser States zurückgeteilt werden kann, ja? Das ist so der der eine Punkt. Der andere Punkt ist, die, und ich glaub, diese Diskussion haben wir auf der Sokotest auch schon mal geführt, die die Frage, ob dein dein dein Tree, deine deine deine Liste an Operationen, ob die halt imutable sein sollte oder nicht, ja? Und bei Git, wie Du gesagt hast, ist sie ja imutable und wenn wir, selbst wenn wir rückwirkend was ändern, fügen wir ja nur andere Operationen obendrauf. Wir erzeugen aber neue Commitisches und so weiter, also auch wenn es quasi für die Benutzung so aussieht, als würden wir was ändern. In in dem eigentlichen Datenschema ändern wir's nicht. So. Und darauf baut ja schon ein nicht kleiner Teil unseres Softwareökosystems auf, ja? Weil so Sachen wie getakte Commits sind Versionen für so Tools wie Package Manager, ja? Und wenn Du die jetzt quasi unter der Haube wieder austauschen kannst, das könnte vielleicht problematisch werden. Gar nicht mal aus aus böser Absicht, sondern einfach 'n neuen Fehlerfall quasi einführen so, ja. Und und deswegen frage ich mich so, ja, ich ich verstehe, warum es das für dich attraktiv macht, aber ich kann auch gleichzeitig sehen, wie sich Leute damit in den Fuß schießen können, die Fußpistole wieder rauszuholen, die Du eben schon tief begraben wolltest, ja. Also das kann auch nach hinten losgehen, oder?
Daniel: Also das ist 'n sehr guter Punkt. Kann ich direkt beruhigen. Nein, nein, keine Sorge. Ganz im Gegenteil. Also es ist vollkommen richtig, dass diese Eigenschaften, die wir da auf von GIT gewohnt sind, tatsächlich sehr positiv und wünschenswert sind. Und da kommen wir wieder zurück, inwiefern JJ eben eine erste Aktion auf dem ist, was wir von kennt und nicht quasi einen Neuentwurf der Eigenschaften fahren lässt, die wir die wir eigentlich gut fanden. Und das wär erst mal eine gute Gelegenheit, ein noch ein weiteres schönes Feature von J. J. Zu erwähnen, ist, wir haben jetzt immer gesagt, man kann Changes einfach modifizieren und daraus folgen ja viele potenzielle Probleme, die Du jetzt angesprochen hast, ist, J. J. Macht das ja nicht intransparent für uns, sondern man kann jetzt die den Änderungsverlauf 1 Changes auch mitverfolgen. Das nennt sich das Evolock in JJ, also heißt der Command, steht für Evolution Log. Und kann man quasi mitverfolgen, wie sich ein Change verändert hat. Nicht nur, wie man den Inhalt modifiziert hat, sondern auch, ob man ihn auf was anderes rebaced hat oder auch die geändert hat. Nennen sie's in JJ, aber sag ich das Gleiche. Und und witzigerweise, das ist nichts anderes als die, die JJ für einen gemacht hat, während man diesen Change bearbeitet hat. Und der stets aktuellste Stand 1 Changes ist, steht vielleicht auch einfach nur der letzte Git Commit, der dabei entstanden ist. Ja, die ändert sich deswegen auch die ganze Zeit. Das ist auch nicht viel anders als in Git, wenn man ganz kräftig die ganze Zeit Rebases macht. Ne. Das heißt, diese Eigenschaften gehen nicht verloren. Und sie sind auch noch für viele Sachen, würd ich sagen, relevant. Und das geht auch eigentlich auch direkt ein auf das Erste, was Du gesagt hast. Ist diese Art von, wie man jetzt mit einem History graphhen in seinem JJ arbeitet, würde ich schon sagen, ist auch etwas sehr Lokales. Das muss man, glaub ich, bedenken. Es gibt jetzt natürlich noch keine JJ Forges, die irgendwie sagen, wir ignorieren mal alles, was wir über Git wissen und warum Tools wie GitHub so gebaut sind, wie sie gebaut sind und machen unser eigenes. Also darüber kann man jetzt, dass ich nur hypothetisch reden. Und jedenfalls kenn ich keine, keine, die relevant sind. Aber aber man würde, ich glaube, diese Fortress würden sich nicht allzu sehr daran unterscheiden von dem, was wir jetzt haben in dem Sinne, dass man dort natürlich dann schon wieder von der profitieren will. Sprich, veröffentlichte Changes sollen natürlich in Stein gemeißelt sein. Das ist eine Eigenschaft, die nicht weggeht. Das heißt, wenn wir jetzt von 'ner Art dunk based Development ausgehen, wo wir sagen, wir haben jetzt irgendwie eine einen Main Branch, wo Leute committen, dann ändert JJ nichts daran, dass wir sagen, ja das was da ist, das bleibt da so und es ändert sich auch nicht. Und wenn ich jetzt irgendwie eine einen Wust an Struktur bei mir lokal hab, aus welchen Gründen auch immer, wo ich Dinge miteinander gemerged hab und sonst was, ist das auch in der Regel ein Belang, den ich nur lokal hab und den ich auch nur unter bestimmten Bedingungen veröffentlichen würde. Es würde wenig Sinn machen, diesen Baum, so wie er bei mir lokal existiert, 1 zu 1 in ein Gitrepository zu pushen, genau auch aus den Gründen, die Du jetzt genannt hast, weil den könnte höchstens jemand anschauen, diesen Baum. Wenn er ihn modifiziert, passieren sicherlich seltsame Dinge. Das ist auch so eine der, sag ich mal noch, Einschränkungen, JayG. Also diese diese Metahistorie von Changes zu pushen, das wurde gar nicht vorgesehen. Es gibt da keine keine Art des Sharing. Also da merkt man dann auch klarer, dass JJ nicht nur ein Tool ist, mit dem man einen Getriebe rauschecken kann und dann verwenden kann, sondern das wirklich eher ein Tool ist, was mit einem Server reden kann.
Jan: Und ist das vielleicht, sorry, wenn ich dich da unterbreche, aber ist das vielleicht so der fundamentale Unterschied, ja? Dass Git ja im Prinzip konzeptionell davon ausgeht, dass Du ne, verteilte Versionskontrolle, dass der State, den Du bei dir hast, eigentlich derselbe State ist wie auf dem Server, derselbe State wie bei deinen Kollegen, derselbe State wie auf deiner CI. So vielleicht mit 'nem mit 1 2 Commits irgendwie mehr oder weniger obendrauf, aber im im Prinzip das ganze Repository ja 1 zu 1 so ist wie bei allen anderen auch, ja? Da da das ist ja auch so dieses dieses ganze von so von wegen Desaster Recovery und so. Also egal, wenn mal deine deine Forge abbraucht oder so, deine dein lokales Repository hat ja alles, was in deiner Forge auch drin ist, hat alles, was dein Kollege hat, hat alles, was Du hast und so weiter, ja? Also im Prinzip dieses 1 zu 1 Klonen so und deswegen heißt es ja auch Klon, ne. Und und JJ will genau das wahrscheinlich nicht, ne. Also macht sich son bisschen frei davon und sagt, na gut, in 1 potenziellen Forge oder selbst wenn man das jetzt noch mit Git macht oder oder wie auch immer, da heben wir im Prinzip das auf, was der wichtige Teil von deinem State ist, aber nicht jeder Commit und nicht jeder Änderung und nicht jeder State Change, der bei dir lokal passiert, ist vielleicht am Ende relevant, ja? Sondern wir schieben halt das fertige Ergebnis deiner Arbeit zurück, aber wir brauchen nicht 738 Zwischenschritte davon mit 100 Megabyte Metadaten dran, sondern am Ende ist halt relevant, was ist das Ergebnis deiner Arbeit und was soll zurückgeschickt werden und und nicht der ganze der ganze Audit Lock davon sozusagen, ja? Ist das so der der fundamentale Unterschied?
Daniel: Ich würde eigentlich sagen, da sind sich beide Systeme eigentlich sehr, sehr ähnlich. Nur diese Eigenschaft, die Du jetzt alle aufgezählt hast, zeigen sich an anderen Stellen. Weil also ja klar, verteilte Versionskontrolle in Git, ne? Warum wir das alles toll finden, das sind geklonen, alles ist identisch und so weiter, aber das stimmt ja eigentlich auch nicht, weil alles, was wir lokal machen, also wenn ich in Branche starte, daraus zu erzeugen, dann existiert der erst mal nur bei mir. Dann kann ich den, ich kann da drauf committen, ich kann ihn auch ermenten und den dann pushen und dann existiert eine Kopie davon auf dem Server. Das heißt also, wir haben da schon verteilt einen konsistenten State. Also ein ein PR Branch in in meinem heutigen Workflow kann auf meinem System, aufm System von meinen Kolleginnen und und auf dem Server jeweils unterschiedlich ausschauen kaum 'n Mechanismus, der das irgendwie managt. Und wir handhaben das eigentlich eher auf der Konventionsebene. Also wir sagen so Sachen wie, wir haben halt einen einen Main Branch und der hat vielleicht auch Branch Protection, die entforct wird von dem Server und dadurch stellen wir eigentlich sicher, dass der bei allen gleich ist. Das heißt, wir haben also die Konvention, der darf sich nicht verändern, was auf Main gelandet ist, bleibt so. Aber witzigerweise kann ich natürlich jederzeit einen Commit bei mir auf meinem Rechner in maine verändern. Findet mich keiner daran. Ich mein, das mache ich nicht, was blöd wäre, aber ich könnte, ne. Das heißt, es ist nur die Kommission, dass ich Commits von maine, also 'n Vorgänger, nicht verändere und der Server entforstet es technisch Und andere Branches sind sind anders, ne. Und das sind J-J-S eigentlich auch das Gleiche. Auch da kann man jetzt vielleicht ein J-J-Feature einwerfen. J-J hat 'n Konzept von. Also es kann anhand von 'nem Regelwerk, was per Default eigentlich ganz gut definiert ist, aber man kann das customizing entscheiden, welche Changes sind. Die sind dann auch besonders markiert, wenn man das Log anschaut. Und es gibt ja gefährtte Warnungen, wenn man versucht, die zu verändern, man kann das dann overriden, genauso wie man das Geld auch machen kann. Aber Jaly hat 'n Konzept davon, welche Changes eigentlich nicht mehr verändert werden dürfen. Und das ist im GH genauso. Und man man man kennt ja auch genau diese Probleme. Also man, das fällt im Alltag oft nicht auf. Wenn man jetzt son ganz normalen Git Workflow Mitglied macht, dann man legt Branches an, man man pusht, andere Leute schauen sich das an, dann man das irgendwie rein. Ist egal, was der Workflow ist. Und das funktioniert alles wunderbar in der Regel. Aber ich hab bestimmt auch schon mal erlebt, wie man dann in der Teufelsküche kommt, wenn so was passiert wie, ich hab da jetzt irgendwie 5 Commits gepusht auf meinen Brunch und dann bin ich irgendwie drauf in Urlaub gegangen und und jemand anders hat sich gedacht, ich mach da jetzt mal weiter, weil's irgendwie dringender geworden oder keine Ahnung. Und hat dann auch auf meinen Brunch drauf gepusht, da Sachen nachzureichen. Und dann komme ich aber zurück, hatte dann hat er mir das vielleicht nicht erzählt, hab ich das nicht mitbekommen. Dann will ich auch wieder auf meinen Brunch pushen, aber ich hab irgendwie erst mal gemacht und Force Push gemacht und dann ist seine Arbeit weg. So was in der Art, ne. Also wir kommen sehr schnell in Teufelskreis, sobald wir anfangen, auf solchen flüchtigen Branches in Git zu kollaborieren. Im Sinne von mehr als eine Person pusht auf sone Brunch. Und das Problem, was wir jetzt in Git auch schon haben und auch wieder nur per Konvention adressieren, indem wir halt sagen, machen wir am besten gar nicht und wenn, dann sollten wir drüber reden, damit quasi derjenige, der ursprünglich mal gepusht hat, dann auch wieder 'n Pull macht und solche Sachen, ne. Und dann empfehlen wir oft immer eher so Sachen wie, wenn Du meinen Pullrequest weitermachen willst, starte lieber deinen eigenen. Quasi mach dir Kopie von meinem Brunch und starte darauf deinen eigenen und dann haben wir quasi 2 davon und welchen von denen wir dann am Schluss reinnehmen, können wir dann noch überlegen, aber wenigstens treten wir uns nicht auf die Füße. Und witzigerweise sind ja alle diese Probleme, die man haben und ich hoffe jetzt, also ich hab euch abgeholt, vielleicht ist das nur son Problem aus meinem Leben, aber also diese Probleme sind, denke ich mal, alltäglich bekannt, ne. Und all diese Probleme sind sind ja der Grund, warum man so Sachen wie Pull Requests und Branch Protection macht in einem Pool wie GitHub. Und dann macht man aber plötzlich das Kollaborieren auf 'nem wieder, also man pusht und forspusht einfach, ne. Und jeder würde die Hände überm Kopf zusammenschlagen, wenn man sagt, ja klar machen wir forspushes auf maine. Macht natürlich keiner, ne. Aber aber auf machen wir's plötzlich hier und wundern uns dann, warum so uns auf die Füße fällt, ne. So. Und JJE knollged diese Realität und sagt quasi, alles, worüber wir jetzt schon geredet haben, dass man also seine History massieren kann, vergangene Changes editieren und ganz weiter, Ist alles eigentlich nur ein Werkzeug, den eigenen Baumarkt Changes in einen Zustand zu bringen, indem man ihn veröffentlichen möchte. Und man möchte diese Informationen, also diese Beziehungen zwischen diesen Changes mit veröffentlichen. Und beispielsweise, ich weiß nicht, wie oft ihr das so in eurem Leben so vermisst habt, es gibt da inzwischen auch Tools dafür, ist irgendwie so. Ihr habt vielleicht mal das Problem, ihr macht irgendwie 3 Dinge, die eigentlich nicht also aufeinander aufbauen, aber getrennte Commits rechtfertigen. Da möchte man 3 Pull Requests aufmachen in seinem Gitap und dann steht man irgendwie ganz schön blöd da, weil man, gibt irgendwie nur dumme Lösungen dafür, ne.
Jan: Viel Cherry Picking dann, ja?
Daniel: Genau, ja, also wie man's macht, macht man's falsch. Das ist halt hier wieder, Gerrit hat das natürlich perfekt gemacht, ne. Ich wollte ja, ich wollte ja nicht Gerrit erklären, aber was man in Gerrit machen würde in solchen Fällen ist, man macht 3 Commits und man pusht diese 3 Commits. Und Gerrit ist ein Change immer genau ein Commits, so wie JJ eigentlich auch, ne. Also er kann hat zwar vergangene Zustände, die er hatte, aber er ist immer genau ein. Und dann kriegt man in GERRET sieht man dann 3 Dinge, die andere Leute reviewen können, so wie man das in GitHub Creditface sehen würde. Aber GERRET weiß, diese 3 Dinge bauen aufeinander auf. Zwar ist quasi der erste kommt das erste, das zweite Commits, das zweite Commits, das zweite Commits, aber es sind 3 Commits, die man wo man nur die Commits anschaut und welchen Commit, der jeweilige Commit als Parent hat, ist einfach nur eine Information davon, als als würde man auf auf Gitter 3 Profits aufmachen und sagen, der eine die pendelt auf den anderen. Kann man ja auch machen. Und es gibt auch, weiß nicht, kennt ihr's dafür jetzt? Das ist son CI Runner, der auch nie so
Jan: richtig populär geworden ist. Nee, aber ich hab so ähnliche Setups mal erlebt mit Pull requests, die auf aufbauen. Bei langläufigen Feature Pull requests macht man das manchmal und so. Ja.
Daniel: Okay, aber aber Sul, es ist
Jan: nicht sinnvoll, aber
Daniel: Ja, ja, also es ist schwierig, ne. Es ist auch, ich hab noch son ganzen Rand in der Tasche, den jetzt gar nicht auspacken würde, ist, inwiefern eigentlich auch der ganze Aufbau wie Gitter funktioniert eigentlich weil das größte ist 'n Fehler. Es macht alles keinen Sinn eigentlich, ja. Und und es könnte alles viel sinnvoller sein, wenn wir 'n anderes Fusionkontrollsystem hätten oder wenn Garet sich durchgesetzt hätte. Aber es ist eigentlich
Jan: Ich spür da son Ja. Son unbearbeitetes Trauma, glaub ich, Ja. Muss ich sein. Passt passt auch
Daniel: nicht in diese Stunde rein, leider auch. Na ja, wie ihm auch sei. Genau, also ich würde, Du hast jetzt gemeint, ob das irgendwie der große Unterschied ist zwischen Tschechio und Gith und ich würde sagen, nee, genau Das ist einfach nur, es sind das sind alles Realitäten unserer Arbeitsweise. Wir haben quasi Modifikationen, die wir vorbereitet haben und wie wollen wir die wollen wir irgendwie managen lokal, ne. Jetzt irgendwie radikale Trunk based Propoennten würden jetzt sagen, nein solltest Du nicht haben, solltest Du immer exakt einen Commit auf deinem Rechner haben, an den Du arbeitest. Nie mehr als den, den pusht Du und dann geht's weiter, ne. Und dann muss man zugeben, da hat man dieses Problem auch nicht, ne. Ich weiß nicht, ob die dich an die Session dahin gehen, der ist da saß, glaub ich, auch 1 von denen drin und hat auch immer so, warum soll ich den Quatsch überhaupt machen? Ist schon richtig, ne, aber na ja. Das Fass wollen wir nicht auch machen. Aber wenn man mal mehr braucht als das, wie eben zum Beispiel zu sagen, ich hab jetzt hier paar Stunden Tacker Taka in meiner ID gemacht und festgestellt, das sind eigentlich 3 Commets. Die bauen aber aufeinander auf. So. Oder oder oder vielleicht noch komplizierter sagen wir, 2 von denen sind unabhängig, der dritte baut auf beiden auf. Braucht quasi beide, aber ich finde, das sind 3 Dinge, die kann man separat reviewen, die kann man separat testen und die kann man separat committen, weil rumrollern, ja? Weil sie halt insofern unabhängig sind, ne? Wollen wir jetzt nicht über Best Practices mitschneiden reden, aber ihr könnt euch vorstellen, was ich meine, ne? So, jetzt haben wir diese 3 Sachen, ne? Und jetzt möchte ich eigentlich schon in der Lage sein und das kann ich mit JJ eben machen, diese 3 Changes in meinem lokalen Repository so zu arrangieren, wie ich's gerade beschrieben habe. Also 2 unten, 1 oben. Und jetzt möchte ich eigentlich eine forge, in der ich diese 3 Dinger pushen kann und die forge mir, also meinen Reviewern, diese 3 Sachen präsentiert, diese 3 Sachen auch automatischen Tests unterzieht und alles. Jeden aber für sich präsentiert nur das, was der Change konkrete Change tut, aber die Abhängigkeit dazwischen respektiert. Das heißt jetzt den den den dritten obenstehenden Change nicht separat versucht zu bauen und dann feststellt, das geht ja nicht, weil da fehlt ja der andere Kram. Mhm. Sondern sagt er, wenn wir den bauen, dann bauen wir ihn so, dass die anderen beiden auch mit drin sind, ne. Und und das ist dann natürlich meine Domäne. Also ich hab lokal diesen diese kleine Dreiecksbeziehung herbeigeführt. Ich pushe die zum Zwecke quasi, das irgendwann auf eine lineare Trunk History zu bekommen, wie auch immer sie linarisiert wird. Und ich kommuniziere die Abhängigkeiten, die ich dafür habe, damit es da landet. Und solange das der Fall ist, ist das Bearbeiten dieser Changes und das eventuell umarangieren, weil ich vielleicht merke, oh, da muss noch 1 dazwischen oder die Reihenfolge ist doch anders, was ich dachte, ist dann ist dann mein Ding. Ist also kein Ding, was damit kollidieren würde, dass irgendwie publizierte History überschrieben wird und das schlecht ist, so wie's in Git eben auch schlecht ist. Weil das ist exakt dasselbe Problem. In Git würden wir genau dasselbe machen. Wir würden genauso die Problem kriegen, wenn jetzt jemand sagen würde, ah ja, schöne nette Dreiheitsbeziehung haben wir da, da füge ich mal meine eigene Arbeit mit hinzu. Natürlich klappt das nicht super schön in JJ, das nicht vorgesehen quasi, aber das ist ist eine ist 'n Workflowproblem und kein Problem, würde ich sagen. Verschwindet nicht mit einem besseren Tool.
Dave: Mhm. Korrigiert mich, wenn ich da falschliege, aber das Letzt, was Du auch beschrieben hast, klingt son bisschen auch nach der Funktionalität von Git Butler oder?
Daniel: Möglich, ich hab's nie benutzt. Ah, aber ja.
Jan: An der Stelle vielleicht kleine Empfehlung zu der Git Butler Folge, die wir schon mal aufgenommen haben letztes Jahr, glaub ich, Dave, ne?
Dave: Ja, irgendwann genau, war da eine Folge, ja. Ja.
Daniel: Also muss auch zugeben, ist ganz interessant. Also ich hab ein einige der Widerworte, die ich so bekommen hab, wenn ich Leute von Jayja überzeugen wollen, haben gemeint so, Git könnte das doch alles auch machen. Das tut's jetzt nicht, aber aber könnte es, ne. So. Mhm. Also man geht dann mit mit dem Argument, ja, es ist mühselig in Git, so, aber es ist nicht gottgegeben, dass es mühselig ist in Git und Git könnte bessere Abstraktionen selber machen und das tut mir nicht. Und das ist auch überhaupt nicht falsch. Und da da tut sich auch was. Hab ich zum Beispiel jetzt entdeckt, ich weiß nicht genau, wie das heißt, aber es gibt eine Option bei Rebase, wo man jetzt sagen kann, das wär son klassisches Beispiel, wie ich's jetzt auch grad skizziert hab. Nehmen wir mal nicht diese Dreiecksbeziehungen, weil das ist noch 'n interessantes Detail, weil Rebase geht ja nämlich nicht über Branches hinweg. Das ist dann ein Ding, wo geht dann sehr schnell versagt. Aber nehmen wir mal was line Jahres. Nehmen wir mal vielleicht, ich hab jetzt 5 Purryquests irgendwie aus irgend 'nem Grund hab ich mich verrannt und deswegen sind's irgendwie 5 geworden und nicht schon 4 davon schon drinnen im Trank. Und die bauen alle einfach linear aufeinander auf. Dann hab ich in 'nem Workflow muss ich 5 haben, die ich dann alle pushe und dann kann ich jetzt, in GitLab und GitLab, glaub ich, geht das überall, dass man die jeweils auf den Vorgänger Comits setzt und Ja. Ne, und dann aktualisiert das automatisch. Das geht dann schon, da bekommt man schon son bisschen, was man möchte. Ja. So, wenn ich jetzt aber den ersten von denen ändere, muss ich nicht nur 'n klassischen machen, den ersten von denen zu ändern, sondern ich muss sicherstellen, dass danach die die die Branch Labels, die ja nur zeige auf diese Story sind, auch mitgezogen werden. Und das passiert, stahlmäßig passiert das nicht. Das heißt, ich mach wie son Ölmännisch, ich check den ersten Brunch aus, ändere ihn. Ich check den zweiten Brunch auf, Rebase ihn, auf den ich grad geändert hab. Dann den dritten und so weiter. So. Anscheinend kann geht das inzwischen out of the Box. Da gibt's eine Option, dass er quasi die die, die er sieht beim Gepäck Früh ist, einfach mitzieht beim. Ist cool. Da hat man schon, das ist schon vielleicht ein Drittel der Miete, die man braucht, was JD quasi einfach so schon kann. Ist eine ist eine Schritt in die richtige Richtung. Ist absolut richtig, ne. Also vieles von dem, was JD kann und leistet, kann man, könnte geht nachziehen, vielleicht halt auch getrieben von JJ. Ich les jetzt auch immer so regelmäßig von Leuten, die irgendwie Sachen basteln für 'n und sie sagen, ja, es ist JJ inspired, aber ich muss dann halt kein JJ nehmen oder so. Ja.
Jan: Das ist vielleicht 'n guter Aufhänger, mal darüber zu sprechen, wo das halt herkommt. Und ironischerweise, so mein Verständnis ist es ja so, dass sowohl dein dein Lieblingsget Tool Gerrit als auch JJ irgendwie aus dem Hause Google kommen. Also ich glaube, Gerrit ja offiziell so von Google und ich glaub, J J irgendwie von einem Entwickler, der bei Google arbeitet, aber glaub ich, kein son offizielles Google Tooling ist, ne, sondern der son bisschen Zeit dafür einfach bekommt und daran arbeiten kann. Aber es wirft ja son bisschen die Frage auf, also muss man erst mal so groß sein wie Google, dass man quasi Git an seine Grenzen bringt und quasi diesen Schmerz fühlt, dann gewillt zu sein, da eben auch zu investieren? Und muss man dann auch so groß sein wie Google, quasi Zeit, Kapazität, Engineering Know how und so weiter zu haben, ein Problem in dieser Größenordnung überhaupt angehen zu können?
Daniel: Ja? Ist ist eine gute Frage. Ich ich glaube, die Probleme von Git haben jetzt skalieren nicht mit der eigenen Größe. Also vielleicht die Probleme von so was wie GitHub, also da gibt's sehr viele, aber jetzt geht an sich, ne, also ich würde sagen, da da da ändern sich jetzt die der Impact für die Organisation nicht notwendigerweise mit der Größe. Also der beim zweiten Teil würde ich aber vollkommen zustimmen, ist, wenn man groß genug ist, sich leisten zu können, was zu bauen, was mehr Sinn macht, weil dann eben Hunderttausende von Entwicklerinnen davon profitieren können. Ist natürlich nur gegeben, wenn man eben groß genug ist, ne. Während halt kleine Läden, wir einfach sagen, ja, wir arrangieren uns halt damit und und hoffen, dass dir dir der Reibungsverlust von den Nachteilen nicht allzu hoch ist, ne. Google, also also zunächst mal, ich hab schon angedeutet, bin kein find das nicht großartig, dass das ein Google Projekt ist. Das ist streng genommen kein richtiges Google Projekt, aber das ist jetzt nicht die beste Eigenschaft daran, aber was interessant ist. Also Google benutzt ja eigentlich selber kein Kit, außer für Android, soweit ich weiß. Die haben ihr eigenes Versionskontrollsystem namens Piper. Was von dem, was ich so vor Jahren mal in Vorträgen gesehen hab, sehr vieles von dem, was ich als problematisch an unserem Status quo betrachten würde, eben besser macht. Also genau auf diese Art und Weise, ne. Und und ich mein, die haben dieses Monoreepo, woraus aus quasi einige Sachen folgen, die man auch braucht. Genau, insofern stellt sich die Frage schon mal eigentlich gar nicht. Also Google hat JJ sicherlich nicht gebaut, von GIT loszukommen.
Jan: Sondern dann, so war das auch gar nicht gemeint.
Daniel: Ja, irgendwie. Müssen wir sagen.
Jan: Aber die konntest nicht halt oder oder Du konntest halt JJ sie konnten JJ nur bauen, weil sie halt eben schon wissen, was die Probleme sind, die sie ja anderweitig vielleicht schon mal gelöst haben. So da so rum kommend er, ja?
Daniel: Vielleicht, aber ich muss es auch zugeben, also dafür, dass ich mich schon sehr für Git Benutzung und Versionskontroll interessiere, bin ich sehr ungebildet, was die Tool Landschaft angeht. Also es gibt ja sehr viele andere auch populär und auch neuere Versionskontrollsysteme, die natürlich alle keine traction haben, realistischerweise. Aber ich merke jetzt son bisschen, wo ich in der J-C-Community son bisschen rumstochere, merk ich, darüber wird viel geredet, ne. Macurial, Sapling, was es sonst noch so gibt. Hab ich gehört, das ist auch irgendwie so was Neues. Also es gibt nicht nur historische Sachen oder halt, was mehr so mal eine gute Chance hatte, aber dann ist, glaub ich, auch Facebook hat's, glaub ich, auch mal verwendet, ist aber auch weg davon. Aber was was man jetzt immer wieder sieht, wenn ich mir Konzepterläuterung von DjJ anschaue, ist, dass oft viele Leute, die diese anderen Tools kennen, dann sagen so, ja, das das haben sie sich übernommen von zum Beispiel. Also ich würde sagen, vieles der guten Ideen von JJ ist eigentlich von meinem Eindruck her eher eine Folge davon, alle sozusagen zu konsolidieren in was Sinnvolles und weniger ein Google hat gesehen, wie's richtig geht. Und will vielleicht auch eine eine Sache deutlich machen, weil's, glaub ich, 'n bisschen Missverständnis war, ist. J. J. Ist entstanden als Hobbyprojekt von 'nem Google Mitarbeiter komplett in der Freizeit. Also nicht auf eine Google Initiative hin. Mhm. Nach einiger Zeit ist er dazu übergegangen, Vollzeit zu machen. Also ihr bekommt von Google, ihr macht das Vollzeit, soweit ich weiß, gibt's noch mehr Google Engineers, die es in Vollzeit machen. Es ist son halbes Google Projekt im Sinne von, es ist kein offizielles Google Projekt, aber sie haben einen Google CIA leider und versuchen also 'n bisschen rauszukommen, weil es passiert nicht in dem Tempo, in dem's passieren sollte. Aber es ist nicht wie Garre, das wär ja auch selber gesagt, ne. Es ist kein Google eigenes Projekt, es wird eben nur entwickelt von Google Mitarbeiter. Und es wird Google intern auch verwendet und dann witzigerweise mit einem selbst geschriebenen Piper backend statt Git. Also das heißt, die Google Mitarbeiter*innen, die JJ verwenden, scheinen auch keinen keine Berührungpunkte mit Git selber zu haben.
Jan: Dann würde ich noch, bevor uns hier die Zeit ausgeht oder Dave wollt grad was fragen, Du sagst Nein, geht's.
Dave: Nee, alles gut. Mach ich erst mal.
Jan: Okay. Weil wir haben das am Anfang schon einmal kurz angerissen. Ich glaube, es ist aber ein sehr kritischer Punkt. Es gibt aktuell keine JJ Native Forges so, ja. Damals viele oder oder was Git halt massiv geholfen hat, sind halt so Sachen wie GitHub und GitLab und so was, ja? Weil die Leute halt dieses UI, diese Convenience, dieses alles eben haben wollten, die Stärken wirklich ausspielen zu können. So. Und ich glaube, so was fehlt halt JJ auch noch, ja? Wenn man sich jetzt zum Beispiel anschaut, wir haben vorhin über über Merch Konflikte gesprochen und wie sie in First Class Citizen sein können oder sind in in JJ und wie cool wäre es denn, wenn Du eine Forge hättest, die das halt unterstützen und abbilden könnte, ja? Wo Du sagst, guck mal hier, das ist mein mein Stand, hier ist ein ein Merchkonflikt und den kann ich quasi damit auch teilen, sichtbar machen, reviewen, ja? Ich muss nicht Dave irgendwie bitten, mal bei mir vorbei zu kommen am Rechner oder Screenshotsharing oder hast Du nicht gesehen, mir jetzt gerade bei diesem bei diesem Merch zu helfen, sondern ich kann das einfach quasi in meine fortschieben. Ich kann sagen, hier, lass uns da mal eine Diskussion zu führen, lass uns das mal gemeinsam anschauen, lass uns das vielleicht auch gemeinsam resolven, ja, weil wir an diesem State auch gemeinsam kollaborieren und weiterarbeiten können und so. Und dann wird es ja wahrscheinlich erst erst richtig mächtig. Also ich bin voll bei dir, ne, für das lokale Arbeiten kann es schon viel stärker ausspielen, aber da ist dann noch so ein ein Riesenhebel hinten dran, der durch die Forge erst kommen würde. So. Und deswegen meine ganz laienhafte Frage, JJ Forge wann so, ja? Übrigens
Daniel: Also ich geborene dir absolut recht. Das ist das ist genau, wie Du's gesagt hast. Ich hab aber eine andere Perspektive auf die Zukunft eigentlich und die ist, dass es hoffentlich zunehmend mehr Leute geben wird wie mich, die sagen, ich benutz das halt. Und und ja, die Zusammenarbeit mit 'ner Forge hat ihre Hackelichkeiten. Ich hätte da son bisschen was so erzählen können, wenn wir noch, wenn ich nicht so viel über einen Quatsch gelabert hätte. Aber es geht, also man man man kann und sagen Sie auch, man kann einfach, aber ich hab schon auch sehr vieles customized für mich, damit's für mich besser geht. Aber aber eigentlich Out of the Box kann man mit JJ auf GitHub zusammenarbeiten und Leute sagen das auch, das einzige, was daran komisch ist, ist JJ auto generiert Branch Nimmst, weil man muss keine benannten Branches haben, in JJ zu arbeiten. Also das gibt's, aber man braucht das nicht. Sie nennen es Bookmarks. Aber man braucht's in dem Moment, wo man irgendwohin pushen will. Und da werden dann einfach auto generierte Namen verwendet, die einfach die Change ID drin haben. Und das ist die einzige Stelle, wo Leute das sehen könnten, dass man JJ verwendet. Und da, was ich so gelesen habe, was Leute sagen ist, da hat mich noch keiner darauf angesprochen, seit ich das verwende. Ich glaube Leute lesen einfach Brunch Names nicht. Und ich hab persönlich auch das Gefühl, ich bin der einzige, der seine Brunch Names liest. Wenn ich mir die Brunch Names von anderen Leuten anschaue, hab ich auch aufs Gefühl, niemand interessiert wird die ausschauen. Da stehen dann einfach nur, keine Ahnung, Stringifizierungen von Gira Ticket Titeln drin. Und ich denk so, ach, so das nicht das nicht Na ja, egal. So. Also das ist die einzige Stelle, wo man so richtig auf die Füße fällt damit. Aber meine Perspektive ist eigentlich, dass es eben, wie gesagt, mehr Leute gibt wie mich und ab dann ein Incentive entsteht für Voges, JJ besser zu supporten und zwar inkrementell. Und das ist derselbe Gedankengang, wie JJ an sich eigentlich populär werden kann, weil ich meine Ausgangslage war, ich ich ich bin zwar interessiert an Git Alternativen, aber ich bin nicht interessiert an irgendetwas, von dem es völlig unrealistisch ist, dass es jemals Git ersetzen wird. Und Git hat einen riesigen Burggraben, der nicht zu überwinden ist, weil jeder kann es, jeder verwendet es, jedes Tool supportet das. Also man ist ein Ding der Unmöglichkeit, das wäre auch einfach Business Unsinn für irgendwelche kommerziellen Unterfangen auf 'n komplett anderes Ökosystem zu setzen und nie zu wissen, ob's nächstes Jahr überhaupt noch weiterentwickelt wird. Es wird schlichtweg nicht passieren. So, heißt, wir haben den einen Keil, den wir reintreiben ist, Leute können lokal machen, was sie wollen. Das mache ich jetzt beispielsweise. So und niemand muss da zustimmen und niemand muss es stören und mir ist es auch wichtig, dass es niemanden stört, dass die Arbeitsweise im Team quasi dieselbe ist wie vorher. So. Und der andere Hebel ist, dass wir dann genügend Leute haben, die sagen, ich fänd es gut, wenn GitHub diese und jene Eigenschaft von JJ vielleicht besser für mich exposd, vielleicht mir eine bessere Art gibt Changes zu pushen, sie aber dann am Schluss trotzdem so wie bisher zu repräsentieren. Zum Beispiel sind Konversationen von Metadaten wär son Klassiker. Das ist, was ich mir jetzt Beispiel selber gebastelt hab. Man kann bei GitLab, das kann das auch nicht. Man kann so Optionen beim pushen mitgeben. Das sind wieder so so Parameter, die beim Push mitgeliefert werden. Oder kann man reinschreiben, was der Titel von sein soll, was die Description sein soll, was dir. Ja, genauso wie auch geschaut, als ich's gesehen hab. Also für die Hörer da im, Jan hat einen weiteren Gesichtsausdruckden Gesichtsausdruck gemacht. Ich fand das ganz großartig. Jetzt hab ich mir halt irgendwie 50 Zeilen Fishcript geschrieben, das in meinen mein JJ Setup zu integrieren. Das ist jetzt nicht, wie ich jedem empfehlen würde, mach's auch so. Aber ich habe halt jetzt 'n Alias im JJ, wo ich mit einem Befehl einen Change Lokal nehmen kann und da wird instant ein Merch request im GitLab draus mit dem passenden Titel. Und wenn ich den lokal editiere, kann ich noch mal pushen und dann wird der Merch request auch aktualisiert im GitLab. So, das ist ganz nett. Diese Dinge könnten natürlich besser werden. Das wäre meine Hoffnung, dass in dem Moment, wo wo JJ User ein signifikanter Anteil an den Forge Usern sind, die Forge sozusagen einfach nachziehen. Mhm. Und nicht eine JJ Native Forge, die tatsächlich großflächig GitHub ablistet, wird wahrscheinlich schon einfach daran scheitern, dass der Laden von Microsoft aufgekauft wird, bevor er mehr als 50 User hat so ungefähr. Darauf warte ich nicht. Wenn sie's nicht selber machen, wird's nicht wird's, glaub ich, nicht nicht relevant passieren.
Jan: Okay.
Daniel: Ja.
Jan: Dave, eine Stunde später, wie überzeugt bist Du von JJ?
Dave: Ehrlicherweise muss ich sagen, ich glaub, da sind sehr viele Dinge so, was Du vorhin beschrieben hast, Daniel, auch so, ne, so im normalen Alltag merkt man das gar nicht und ich glaub, dass ich hatte ich in meiner gesamten Entwicklerzeit, glaube ich, viel zu normale Alltag immer so. Ich mein, ich kenn dieses eine Problem mit von wegen, man hat irgendwie PRS, die auf anderen PRS aufbauen und so was als, das ist schon etwas, was also wo ich auf jeden Fall durch 'n Vorteil sehe, aber sonst sind meine Berührungspunkte, glaub ich, nicht so stark. Was ich auch cool fand, war natürlich das mit diesem hier, conflicted States. Das ist so etwas, was ich sehr cool finde, so, weil Merchkonflikt ist, glaub ich, etwas, wo man häufiger sich denkt, ah, muss das jetzt sein? Von daher also schon coole Aspekte. Ich glaub aber, auch den Punkt hast Du genannt, so, man muss das, glaub ich, echt mal wirklich anfühlen und selbst machen. Und ich, also ich fühl mich jetzt auf jeden Fall durch dicht ermutigter, das zu tun.
Jan: Das freut mich. Ich glaub, also ich hab's ja auch noch nicht verwendet, zumindest nicht länger als einmal installiert und so quasi 'n leeres Repo aufgemacht und so, den mir die Befehle mal irgendwie angeguckt. Mein Eindruck auch jetzt nach dem Gespräch, ich das das ist eigentlich seine Stärken in sonem hochgradig agilen Umfeld am allerbesten eigentlich ausspielen kann, ja. Weil Du halt vielleicht dann eher die Situation hast, dass Du so Dreiecksbeziehungen hast zwischen zwischen deinen States, dass Du diese mehrstufigen Pull requests irgendwie aufbauen musst. Wenn Du aber in einem, ich will, ich wollt sagen, langsameren umgeben, oder das klingt zu ab, das mein ich gar nicht, aber ne? Wo halt 'n 'n Pull request auch mal, also wenn wenn der halt lange liegen bleibt, dann machst Du erst mal was anderes, aber Du baust nicht direkt danach das nächste Feature darauf auf, ja? Und wenn Du 'n Konflikt hast, dann muss der nicht direkt heute behoben werden, sondern dann klappst Du deinen Laptop zu und machst halt übermorgen weiter so, ja. Wenn Du dir sowas erlauben kannst, weil es genug andere Arbeit gibt, an der Du auch parallel noch arbeiten kannst, dann ist es, so mein Eindruck, 'n bisschen bisschen schwieriger für JJ da, seine Stärken auszuspielen.
Daniel: Wenn wir noch Zeit haben, würde ich noch was dazu sagen.
Jan: Ja, bitte. Ich empfinde es
Daniel: quasi eher als andersrum. Also ich muss zugeben, ich bin, glaube ich, in einem eher langsamen Projekt derzeit. Will jetzt nicht, weiß nicht, ich hoff. Hallo liebe Kollegen, falls ihr diesen Podcast jemals wollt. Natürlich.
Jan: Nein, also ich mein,
Daniel: Du hast schon recht, ne. Aber ich würde sagen, gerade weil es langsamer ist, gerade weil so Dinge passieren, wie man macht einen auf und der der muss jetzt nicht heute rein, wird er plötzlich auch 4 Tage lang nicht angeschaut und dann hängt er so rum, aber dann sag ich, ich möchte aber noch darauf aufbauen und möchte jetzt nicht warten, dass der drin ist, ne. Also gerade weil es langsam ist, türmt sich für mich lokal die Arbeit auf. Also genau das Phänomen, was man mit Trump Based Development im radikalen Sinne eigentlich vermeiden möchte, passiert dadurch und wird mit JJ Managebarer. Je agiler, wie Du's jetzt genannt hast, die Arbeitsweise ist, desto weniger würde das eigentlich passieren, weil man eher sagt, wenn Du mit fertig ist, komm da rein, wird gepusht, fertig. Sache gegessen, ne. Desto näher kommt man an den Punkt, ich hab eher nur einen Commitment und fertig, ne. Ich benutze dir auch ganz viele Repos, die ich jetzt auch einfach als einzelner Mensch verwende. Das ist auch kein Problem. Und da find ich auch einfach nur die Ergonomie schon besser. Dafür reicht's mir schon. Also das würde, was ich zu Dave sagen würde, ne, ich b ich gehe voll mit zu sagen, meine Probleme sind vielleicht nicht die Probleme von allen und vielleicht auch hausgemacht. Und und und viele sagen einfach, ich schiff da drum rum und empfinde das deswegen nicht als Problem. Ich fahr halt vielleicht ganz gerne auf die Sandbänke drauf und deswegen brauch ich irgendwie 'n Boot, was da wieder runterkommt. Aber aber schlichtweg für auch triviale Workflows ist die Ergonomie von JJ attraktiv. Kannst empfehlen, auch einfach nur dafür zu nutzen. Also jedenfalls, wenn man auf der gerne unterwegs ist, es gibt auch Tuees und so weiter, aber auch dafür ist es schon besser als Git für für meinen Geschmack. Und ich hatte noch einen Gedanken, den mir jetzt entfallen ist.
Jan: Ja, also auf alle Fälle hat das, das das würde ich auch unterschreiben, sodass Du so deine Change IDs nicht komplett ausschreiben musst, sondern in der Regel die ersten paar Characters halt irgendwie reichen, das automatisch findet aufgrund von deinen letzten paar Revisions. Also es es es benutzt sich einfach schon moderner als Git, weil es halt einfach jünger ist, so, ja. Also da sind viel Learnings auch einfach ergonomisch eingeflossen. Das ist alles super fair, glaub ich, NDR.
Daniel: Ich hätte noch ein eine Sache, die ich, glaube ich, ganz gerne erwähnt hätte, ist, weil wir darüber jetzt gar nicht eingegangen sind, nämlich Workflows, die ermöglicht werden von JJ, die mitgate überhaupt nicht möglich sind. Das ist eine Sache, die ich ganz spannend fand. Ich jetzt, benutze ehrlich gesagt kaum, aber ich hab sie benutzt. Es nennt sich der Mega Merch Workflow, weil das fand ich ganz spannend. Klingt schon cool. Ja, das klingt klingt schon mega. Ja, genau. Ich fand's spannend, weil weil das ist eigentlich jetzt die die Stelle, wo man wirklich sagt, so, was baut sich eigentlich auf JJ auf, womit man vorher gar nicht gerechnet hat? Wir haben uns viel darüber geredet, sagen Schmerzen, die man mit getat, die man mit JJ nicht hat, ne? Wir haben nicht darüber geredet, was was sozusagen enabelt wird von von JJ und seinen Konzepten. Und dann denke ich kurz mal die mega Matchwork erklären, der auch dem gerecht werden soll, sodass man viele Sachen irgendwie parallel in Flight hat, die vielleicht jetzt nicht zwingend voneinander abhängen. Das heißt, stimmen wir so, haben wir 5 Sachen, die mehr oder weniger miteinander zu tun haben. Und man möchte aber einfach weiterarbeiten und möchte so für sich lokal so tun, als wären diese 5 Sachen schon schon Teil von Trump. Und die haben aber keine feste Reihenfolge. Dann ist die Idee des Workflows, dass man sagt, man macht einen Merch Change, der alle diese 5 Sachen als hat. Deswegen ist er mega, sieht er aus wie son Oktopus, aber müssen nicht unbedingt 8 Arme sein. Und dann arbeitet man auf Basis dieses dieses Merch Changes, macht man meistens noch einen dann oben drauf und und da drin macht man dann seinen neuen Kram und da könnte man dann eben so Sachen machen wie, ja, vielleicht habe ich jetzt einen sechsten Change kreiert. Vielleicht habe ich aber gemerkt, so, oh, da ist ein Fehler gewesen in dem, was ich da in einem von diesen anderen 5 Changes gemacht hab. Und dann kann man das alles dort machen und dann mit dem Squash Befehl in JJ sagen, ich möchte das gerne dahin schieben, wo es eigentlich herkommt. Und das ist das Charmante und das ist eine dieser Sachen, die rauskommen, aus dem, was ich am Anfang gemeint hatte, mit Merges sind nicht, ich mache einen Merge und dann habe ich einen Merge Commit, sondern Merges sind 'n Zustand, permanenter Zustand. Und wenn ich jetzt in einem Merge Commit aus 5 anderen Sachen eine Sache modifiziere, also eine Zeile, die ich schon in einem oder anderen 5 Sachen modifiziert hab, dann kann ich einfach mit 'nem Squash Befehl sagen, ich möchte, dass dieser Change, der jetzt in meinem Change hier trifft, also dieser TÜV, der in meinem Change Stern ist, runterwandert in den anderen, wo er eigentlich reingehört, weil es eine Nachbesserung ist. Da gibt's sogar einen extra Befehl dafür, also in Squash kann man absorb machen, das Ähnliches gibt's auch an Git, das ist auch sehr ähnlich. Das sucht quasi den Change, wo das reinpasst und tut's da rein. Und das fand ich echt ganz spannend, weil das ist was, man mit Git, man würde gar nicht auf die Idee kommen, es zu machen, weil selbst wenn es gehen würde, man müsste so viel drum rum basteln, damit es funktioniert. Warum überhaupt ne? Und das ist auch 1 dieser Workflows, der substituiert ist, was ich im ganzen Anfang meinte, wenn Leute sagen, ich vermisse meine Working Copy. Ich möchte zwischen Branches hin- und herwechseln und beim hin- und herwechseln Dinge quasi committen oder halt Commitment partiell, also mit mit minus p, also partielle Staging machen sie dann committen. Und ich nehme quasi meine Working copy von Brunche zu Brunche und streu immer son bisschen was rein. Das macht der mega Merch quasi Stateful. Ich habe quasi, also der der der der Merge Committe den mega Merch ist quasi das Äquivalent zu 'ner Working Copy, die ich von a nach b bewege. Nur dass sie nicht von a nach b bewirkt wird, sondern sie ist gleichzeitig auf allen Sachen, die entfight sind. Und das fand ich sehr erhellen, muss zugeben, dass es nicht universell für jeden Zustand ist. Die, was ich gelesen hab, ist, so Leute, die arbeiten einfach nur so, sozusagen das ist meine Arbeitsweise. Alle Arbeit befindet sich unter diesem Mega Merch Commit. Ich hab das aber schon teilweise erwähnt und das war eigentlich ganz, ganz charmant.
Jan: Das klingt auch ganz interessant für so CI- oder Preview Systeme, ne. Wenn Du einfach sagen kannst, ich verbinde hier mehrere anstehende Changers irgendwie zusammen und schau mir mal an, wie die so
Daniel: Exakt, ja.
Jan: In den Union dann irgendwie funktionieren.
Daniel: Mhm.
Jan: Cool, dann haben wir, glaub ich, schon einiges hier durchgearbeitet. Dave, hast Du noch letzte Fragen?
Dave: Oh ja, also ich würd noch eine Frage aufmachen. Ja. Ganz anderes Thema. Ich ich philosophier ja sehr gerne. Und ich hab, das Ding ist, bei so Namensgebung von so Softwaresachen frag mich immer, wo kommt das her? Und natürlich ist es sehr naheliegend, J J kommt von Jujitsu, ist ja eine Kampfsportart und tatsächlich hab ich mal nachgeschaut, wofür das eigentlich steht tatsächlich. Hast Du wahrscheinlich auch gemacht, Daniel, irgendwann mal, oder?
Daniel: Ich hab's ich glaub, ich hab gelesen, was Du jetzt erzählst. Ich bin mir nicht mehr ganz ehrlich.
Dave: Ach so, nein, ach okay, genau, weil ich hab gesehen, es heißt also nachgebende Kunst oder sanfte Kunst, beziehungsweise die Kunst der Flexibilität beziehungsweise Anpassung und da wollte ich einfach nur mal deinen Take hören, wie Du findest, wie sich das widerspiegelt in in in JJ.
Daniel: Also, jetzt hoffe ich gar nicht darüber nachgedacht. Ich erinnere mich an eine andere Aussage, die ich irgendwo, ich glaube im Discord aufgeschnappt hatte, das irgendwie darum, ich hoffe, ich verwechsle da jetzt nicht Kampfsportarten. Ist Du jetzt so nicht auch die Sportart, bei der es darum geht, die Kraft des Gegners zu seinem Nachteil zu nutzen?
Jan: Ja, das ist
Daniel: Und das das war, glaube ich, der Vergleich, den da jemand angestrengt hatte sozusagen. Also es es verwandelt sozusagen die die die die Mühen, die man überwinden muss, die das die Versionskornatzeugs geben, gleicht es quasi leicht, ne. Das ist quasi der Hebel als Software so ungefähr. Fand ich eigentlich auch eine interessante. Aber ich fand, dass Du gesagt hast, auch auch spannend, aber ich bin einfacher Typ. So heißt also, ich benutze
Dave: es. Na. Ja. Fand fand ich lustig. Das war tatsächlich auch Gesprächssinn mal vorhin am Essenstisch bei uns. Und wir dachten, es war kraft mal gar, wo das mit dieser Energieübertragung ist, aber
Daniel: Ja. Ja.
Dave: Irgendwie so was.
Jan: Ja. Also Jujitsu hat tatsächlich so mehrere coole diese Analogien, ne. Das eine ist dieser dieser ganze Aspekt von von Kraftumlenkung und so, ja. Aber Jujitsu hat ja auch so ganz viele Inspirationen von anderen Kampfschauarten so, ne. Also es ist Karate drin, es ist Judo drin. Und das ist natürlich dann auch irgendwie cool, so das als als Metasportart oben drüber, so wie halt JJ so als als Meta Versionierungssystem eben über sowas wie wie geht und so dann Ja, das
Daniel: trifft's vielleicht am besten, ja. Aber ich werd mal in den Discord suchen, ob ich eine Diskussion dazu finde, wo der Autor vielleicht sich geäußert hat zu seiner Namenswahl.
Dave: Da war spannende Takes.
Jan: Cool. Es bleibt spannend, auch wenn wir mit dem mit dem JJ Thema durch sind, weil wir haben noch, was, Dave?
Dave: Alter, pick of the day. Wie fresh fandest Du's, Daniel?
Daniel: Megafresh. Ja. Ja, voll. Mir ist noch 'n dritter Pick eingefallen, als ich die Musik gehört hab.
Dave: Oh, ich
Jan: find's crazy. Vielleicht vielleicht kannst Du einen an Dave abgeben. Oder Dave, ist dir mittlerweile 1 eingefallen?
Dave: Ja, mir ist währenddessen 1 eingefallen. Also weil also ich versuche ja eigentlich, also was ich meistens versuche, ist irgendwie während der Folge Inspiration für meinen Pick of the day zu bekommen oder etwas, was mich momentan irgendwie beschäftigt oder irgendwie beeinflusst. Und tatsächlich ist es jetzt eher Zweiteres, denn mein Pick of the day, ich ich geh mal 'n bisschen in in in in bisschen Kontext und zwar, was ich immer supergerne gemacht habe, ich mach ja Musik privat auch und ich hab immer 'nem Kumpel, mit dem ich auch zusammen
Jan: Du machst Musik.
Dave: Ja, ich hab tatsächlich
Jan: Das ist jetzt für mich ja
Dave: auch neu. Also auch neu, wow. Also ich glaube im Podcast hab ich noch nie gesagt, nee genau. Ich hab also, glaube ich hab auch 2 EPs gemacht mit 'nem Kollegen, wir sind son Rapduo gewesen oder immer noch.
Daniel: Keine Ahnung. Link in den Shownotes oder?
Dave: Link in den Shownotes.
Jan: Auf wem, ich hab ich bitte darum.
Dave: Und was wir immer gemacht haben, gerne ist so so gegenseitig immer so Geburtstagstracks gemacht, ne, also dass wir irgendwie, weiß ich nicht, 16 Zeilen runter geschrieben haben, vielleicht noch 'n Hook oder so dahinter und dann immer den anderen so zum Geburtstag gratuliert, das wär immer so Dieses Jahr hatte ich sehr wenig Zeit und dacht mir so, hey, aber wir sind ja jetzt im Zeitalter von AI angekommen. Mal gucken, wie viel wie viel Macht in diesen Tools steckt und da ist natürlich, was ich jetzt nenne, SunoAI. SunoAI ist nämlich halt quasi eine AI, die dir quasi komplett ermöglicht, halt die die Instrumentals zu machen, die Vocals. Und Du kannst halt auch deine eigenen Lyrics einfügen. So hab ich das halt natürlich genutzt, dass ich gesagt habe, hey, hier, das sind meine Lyrics, mach das mal und mach da daraus irgendwie 'n krassen Rap Song irgendwie an der Stelle. Und ich war schockiert, wie erstaunlich gut das geklappt hat. Also irgendwie den Text, den ich da in in 'ner Viertelstunde geschrieben habe, einfach eingetippt, wo ich mir dachte, oh, das ist schon teilweise kompliziert geflat und so. Der hat da so perfekt auf den Tag hinbekommen, dass irgendwas dazu gepasst hat. Es klang so schön und so gut, wo ich mir dachte, also krass, dass es geht. Gleichzeitig hab ich das sehr demotiviert quasi eigene Musik zu machen, weil ich mir denke, in der Qualität und auch in der Geschwindigkeit, wie das entstanden ist, krass. Also ist natürlich auch die Opportunity für Leute, die halt kreativ sind und Texte schreiben, da sie jetzt auch in Musik umzuwandeln, die vielleicht sagen, hey, ich hab nicht die passende Stimme dafür oder so. Also schon cool, aber auch sehr, also ich war sehr erstaunt, wie gut das funktioniert hat.
Jan: Also ich bin bin immer noch geflasht von deinem von deinem Musikgeständnis hier. Aber Suno ist natürlich auch cool. Ich weiß gar nicht, ist der der der Soundtrack, den wir zu unserem letzten Loturm Trip gemacht haben, der war ja auch mit Suno erzeugt. Ich werd ja glaub ich irgendwo auf unserem Instagram, also auf dem Loturm Instagram Profil irgendwie Stimmt.
Dave: Son Ballermann ist nicht so der Abrres Ski.
Jan: Aprres Ski. Ich bin ja nicht so der der Abrres Ski Fan, aber das Lied kann ich auswendig, muss ich sagen, ja.
Dave: Jan, ich hab Videos, die das Gegenteil beweisen. Wow. Wow. Wow. Die Shownotes.
Jan: Okay, ich bin gespannt. Ich bin gespannt. Dann hab ich auch einen Pick dabei, was viel Profaneres. Und zwar hab ich eine eine neue Serie gefunden, die ich wieder am Bingen bin, beziehungsweise noch nicht ganz kann, weil ich weiß gar nicht, ob alle Folgen schon Ah doch ja, ich glaub, sind alle schon draußen. Und zwar eine Netflixserie, die da heißt Hostage. Und zwar geht es darum, dass die englische Premierministerin und die französische Präsidentin zu einem Gipfeltreffen zusammenkommen und parallel dazu der Mann der englischen Premierministerin entführt wird und dann geht quasi die Sache so richtig rund. Und ich glaub, so viel kann man spoilern aus der ersten Folge. Parallel dazu wird auch dann die französische Präsidentin erpresst. Ich will nicht zu viel verraten. Das ist nämlich son bisschen spannenderer Teil noch, was da alles so passiert. Und eigentlich müssten sie zusammenarbeiten, aber jeder hat halt so seine eigenen Interessen, weil die eine will ihren Mann nicht verlieren, die andere was anderes nicht. Und das ist, ich mag ja so politische Thriller und so, ja. Und das das funktioniert halt wunderbar so. Und das ist vielleicht eine eine coole Empfehlung, wer so, weiß nicht, wer Gongirl irgendwie cool fand als Film oder so, ja, der kann, glaub ich, auch mit mit soner Serie viel viel anfangen.
Dave: Ich ich find interessant, also die Serie scheint aber auch sehr kontrovers diskutiert zu sein, weil ich seh sehr viele Ein Sterne Bewertungen, ich seh auch sehr viele 5 Sterne Bewertungen, find ich find ich krass. Also entweder mag man es oder man hasst es.
Jan: Ja? Was was sind die Ein Sternebewertungen?
Dave: Ah, weiß ich, hab ich grad nicht geschaut.
Daniel: Okay.
Jan: Also es ist halt sone sone europäische Produktion. Also man man merkt halt schon, ne, es sind viel viel englische Akzente, viel französische Akzente drin, was es eben O-Ton ehrlicherweise auch manchmal 'n bisschen schwierig macht so beim beim Zuhören und beim Gucken. Aber ich find das ich find das ja irgendwie immer immer cool, weil grade so bei bei britischen Serien gibt's ja so viel verschiedene Akzente, die irgendwie son Charakter auch mitbringen irgendwie am Ende immer noch. Und das ja, weiß nicht, find ich fand ich cool. Hab jetzt erst 'n paar Folgen geguckt, war gestern dann auch wieder viel zu lange wach deswegen. Und sind, glaub ich, nur 6 Folgen oder so. Hat man dann auch schnell durch und lohnt sich auf jeden Fall. Nice.
Daniel: Kommt auf die Liste. Also meine Ja, die ist die ist sehr lang, die Liste,
Dave: glaub ich.
Jan: Also meine meine, wenn das Meine Liste so geht wie mir, mein mein Medienbacklog ist irgendwie
Daniel: fast
Jan: so groß wie meine Steam Library, glaub ich.
Dave: Auf auf die werde ich niemals schauen Liste, richtig, Daniel?
Daniel: Genau, ja. Na ja, ist schon nicht ohne eine Liste.
Jan: Ist auch so wie bei diesen ganzen Pocket oder Insta Paper, so Read Later Service, dass das auch nur son, da kommt immer mehr rein, aber nur ganz wenig wieder raus gefühlt.
Daniel: Oder Tiere.
Jan: Ja, aber das ist weniger persönlicher Schmerz, so.
Daniel: Das wär
Jan: ja. Das ist auch 'n strukturelles Problem, aber da leide ich persönlich weniger drunter. Okay. Den Abschluss darf dann Daniel machen, der heute sogar 2 Picks
Dave: Nee, 3.
Daniel: Nein, aber 'n Scherz.
Jan: Ich hab nur 2.
Dave: Aber wirklich, also wirklich nur 2.
Daniel: Ist mir schon unangenehm, dass es 2 Das
Jan: ist wirklich nur 2, sagt der Typ, der grade von 10 Sekunden sich seinen ausgedacht hat, ja. Also das war Aber
Dave: jetzt nein,
Daniel: aber ich war jetzt so hyped und dacht mir,
Dave: oh, jetzt kommen 3 und jetzt Mein Erwartungshaltung ist jetzt bei 3, deswegen also ich hoffe, dass dir während Du die 2 jetzt vorträgst, noch 'n dritter, was dazu kommt.
Daniel: Chancen steht schlecht.
Jan: Der eine ist für Dave bestimmt superinteressant, der andere ist für alle Hörerinnen da draußen, glaub ich, ganz oder für viele da draußen ganz praktisch. Dann ja, schau. Ist los.
Daniel: Da bin ich jetzt gespannt, welche?
Dave: Auch. Auch
Daniel: bin mir nicht sicher. Ja. Genau. Ja, ich habe einen technischen und einen absolut nicht technischen Pick. Ich konnte mich nicht entscheiden, Jan hat mir lustigerweise erlaubt, beide vorzustellen. Der Technische ist, der hat mir diese Woche sehr erhält, weil er unsere CI Pipelines im Projekt massiv beschleunigt hat, weil ein Schritt den wir da machen und das machen wahrscheinlich sehr viele ist, wir bauen Docker Container. Und zwar nicht sie zu deploylen, sondern nur weil sie das Bild environment für die eigentlichen für die eigentlich Test- und Bildausführung beinhalten. Das heißt, fürs Frontend ist da das Teuerste, was da passiert ist, eine und und im fürs.net Backend, das ist ein. Und das dauert schon so 5 bis 10 Minuten, je nachdem. Aber da wird natürlich Cashing gemacht. Das heißt also, wenn man für für den Branch, von dem man das baut, schon mal son Container gebaut oder Image gebaut hat, dann wird's einfach gepusht ins in in in der und dann quasi zu Beginn, da haben wir das vielleicht, schon holen wir das. Und dann wird ein gemacht, der dieses Image als Cash verwendet und dann ist das sehr schnell. Also das kennt man ja. Docker braucht dann vielleicht ein, 2 Sekunden, festzustellen, da hat sich gar nix am Dockerfall und am Kontext geändert. Alles cool. Mich hat aber gewundert, warum dieser sy Job dann trotzdem im Cash Hit Fall irgendwie 2 Minuten braucht. Das kommt mir ein bisschen lang vor, zudem ja dann alle anderen Jobs darauf warten, weil sie ja diesen Cash benutzen wollen. Und hab ich festgestellt hab, das dauert einfach 2 Minuten, weil der 4 Gigabyte Docker Image runtergeladen wird, nur dann zu gucken, dass es nicht gebaut werden muss. Hab mich gefragt, warum eigentlich runterladen? Wenn wir's nicht bauen, müssen wir's da auch nicht runterladen. Es reicht doch das Wissen, dass wir's haben. Ja, turns out, es gibt 'n heißt das, sondern Feature. Ist jetzt wahrscheinlich auch nicht sonderlich neu, ist aber nur für mich neu, die Möglichkeit, Cache Backends zu verwenden. Ist ein bisschen ein anderes Format. Also man kann da genauso so oder einfach auch dafür benutzen, aber das Metadatenformat ist ein kleines bisschen anders. Und was neu ist an dieser Implementierung ist, dass es lazy caching macht. Das heißt, man sagt, woher man den Cache haben möchte und es schaut dann erst mal nur in die Metadaten und stellt fest, oh, den Layer, den haben wir schon, dann machen wir mal weiter. Und erst wenn es tatsächlich irgendein Cache Miss hat und dann einen Schritt in einem Layer neu ausführen muss, lädt's das tatsächlich runter von dem, was für uns bedeutet, dass ein ein Cache Hit jetzt nicht 2 Minuten Download von 'nem 4 Gigabyte Image mehr ist, sondern etwa 30 Sekunden, rauszufinden, dass es sein hundertprozentiger Cache Hit ist. Fand ich eine großartige Sache. Und dieses Feature kann dann auch tatsächlich in dem Fall von 'nem Cash Miss auch die neue Version pushen. Also ganz wunderbar, kann ich nur empfehlen, wenn man so was verwendet. Und langsam Pipelines sind direkt nach schlechtem Versionskontrollsystem ja irgendwie so der größte Pain im Entwickleralltag.
Jan: Facts.
Dave: Ja. War das jetzt der Moment nicht,
Jan: dass ihr
Dave: Der hat mich, der mich umgehauen.
Jan: Okay. Ja, das war's.
Daniel: Ja. Gut, ich hätt
Jan: das eher andersrum gedacht,
Dave: aber Okay, was heißt, der Zweite wird mich noch mehr umhauen. Okay, das
Daniel: jetzt So, der der Zweite ist jetzt, der der nutzt jetzt die Zeit, die Du gewonnen hast, weil Du nicht mehr auf SEPeplines wartest. Und zwar Leitung. Das ist ein ein Wörter Puzzle Spiel von der New York Times. Haben ja sehr viele so Spiele, die haben damals ja auch Wordle gekauft. Mir war das gar nicht so bewusst. Also die haben auch eine Subscription oder Geldanwerfen und ganz viele Spielspielen und so weiter. Das Ding kann man aber umsonst spielen. Das nennt sich Connections. Und es einfach nur ein tägliches Puzzle, wo man 16 Wörter bekommt. Also ob ich sie auf Englisch gibt's auch deutsche Versionen, davon fand ich aber nicht so gut. 16 Wörter bekommt und man muss sie in 4 Gruppen aus 4 Wörtern gruppieren. Und das teilweise schwerer, als man denkt, weil dann eben oft auch semantische Zusammenhänge zwischen diesen Wörtern suggeriert werden, die gar nicht existieren. Dann findet man vielleicht 3 zusammenpassen, aber nicht 4, also jetzt eigentlich ganz andere. Mhm. Und das kann man täglich spielen. Es gibt son schönen Share Button, wo man seinen Freunden dann schicken kann, wie gut's gelaufen ist, wie viel Fehler man gemacht hat. Man darf halt bis zu 3 Fehler machen, sonst hat man verloren. Und da, wenn man bezahlt, kann man auch das Puzzle von anderen Tagen spielen, aber das muss man eigentlich nicht machen. Ein ganz großartiger Spaß, bei dem man auch die eigenen Englischkenntnisse ein bisschen verbessern kann. Ich kann nur empfehlen, beim Spielen nicht die Wörter zu googeln, die da drin vorkommen, weil ganz oben kommen sofort Diskussionen über das heutige Connection Puzzle, sondern ist sofort gespoilert. Aber für mich fair game ist, ich schau auf, was Wörter vielleicht noch bedeuten könnten, also Bedeutung haben, die ich vielleicht nicht kenne. Oder Wikipedia, das ist quasi kein kein Spoiler und macht viel Spaß. Mhm. Und dauert ungefähr so lang wie eine viel zu lange CI Pipeline. Und dann ist man für einen Tag auch drin.
Jan: Ist ist das das, was
Dave: man so, wo man diese 4 Begriffe in eine Reihe bringen muss dann immer? Also wo man das so
Daniel: Ja, man hat einfach son 4 auf 4 Feld, man wählt dann 4 Stück aus.
Dave: Ach so, 8, ja.
Daniel: Wenn das dann stimmt, dann rutschen die hoch als die erste Reihe und es bleiben die restlichen 12 halt.
Dave: Ja, okay, doch, doch, doch. Ah, okay. Ja. Ja, cooles cooles Konzept.
Jan: Ja, wusst ich doch, dass dir das gefällt.
Dave: Ja, doch, also das find ich schon, find ich schon nice.
Daniel: Alright.
Jan: Dann sind wir durch. Wunderbar. Daniel, 1000 Dank für die Zeit. Danke, dass Du hier über eine Stunde jetzt schon Rede und Antwort gestanden hast zu JayJ und uns alle aufgeklärt hast, wieso Geht vielleicht auch stellenweise unter der Haube funktioniert. Und hoffen wir mal, dass wir viele, viele Leute da draußen zu JJ vielleicht noch nicht konvertieren, aber vielleicht zumindest mal motivieren konnten, sich das mal anzuschauen. Und dann bauen wir vielleicht gemeinsam über Zeit den den Druck auf, den die Forges benötigen, diese ganzen JJ Features peu à peu auch zu implementieren, ja?
Daniel: Ja, vielen Dank für die anderen.
Jan: Immer gerne. Dave, danke auch dir für die Zeit, ja. Danke gerne alle Hörerinnen und Hörer da draußen, die zugehört haben. Ihr könnt uns wie immer Feedback hinterlassen über Youtube, Spotify, iTunes Kommentare. Ihr könnt uns auf Social Media schreiben. Ihr könnt auf unserem Discord Server vorbeikommen und diese Folge mit uns diskutieren. Ihr könnt uns E-Mails schreiben an Podcast at Programmier Punkt Bar. Wir freuen uns immer von der Community zu hören, egal wann, wo und wie. Wir lesen eigentlich fast immer, fast alles, fast zeitgleich mit. So sagen wir mal. Und ja, wir hören uns spätestens dann nächste Woche wieder. Bis dahin,

Jujutsu mit Daniel Danner

Shownotes

Picks of the Day

Connections

GitHub Actions Cache für Docker Builds

Hostage

Suno

Speaker Info

Daniel Danner