 So, hallo. Vielen Dank, dass so viele da sind, obwohl da draußen mal die Batches der restlichen verkauft werden. Ich bitte da bleiben. Ich stelle uns kurz vor. Das ist der Julen, ich bin der Matze. Wir kommen aus 141,28, einer kleinen Hochschule mit viel Bergen und Wald außen rum, die zwei Wintersemester hat. Also, eins mit Schnee und eins ohne. Weniger, kein Schnee gibt es nicht im warmen Wintersemester. Genau. Und wir erzählen heute was über GIT-DIT in der Julien Finkern. Ja, also, wir sind zwei Studenten, wie schon gesagt. Und wir wollten ein Semesterprojekt machen, um andere Dinge, die man ansonsten tun müsste, zu umgehen. Und wir hatten die Idee, ich hatte mal irgendwie mit Device Trees zu tun. Und mir ist aufgefallen, hey, es gibt die Kernelkonfigur, es gibt den Device Tree. Und beiden hat man irgendwie Dinge, die man haben will. Und es gibt Leute, die nur dafür angestellt sind, die Kernelkonfiguration, für irgendwelche Produkte anzupassen, so dass die auf irgendeiner Platine läuft. Und wir dachten, hey, da wäre es ein Tool, wenn es ein Tool gibt, das den Abgleich macht. Ja, gab es schon. Der Witz ist, dass das Teil released wurde, nachdem wir den Vorschlag eingereicht haben, um das Projekt gewillig bekommen. Aber bevor wir angefangen haben, daran zu arbeiten, ist uns dann nachhinein aufgefallen. Ja, da war die Frage, macht man da irgendwie weiter, weil das Tool, was es gab, da war es schon richtig gut. Und das konnte auch mehr, als wir mit unserem Bash und ABK kurzzeitig zusammengefummelt haben. Also war die Frage, ja, neues Projekt. Ja, auf der letzten GPN entstand dann eine gewisse Idee, die euch Mats erklären kann, weil ich nicht mal mehr weiß, was da überhaupt gelaufen ist. Ja, genau. Also der Profpatch, ich weiß nicht, ob der da ist, ich sehe ihn zumindest nicht. Wir hatten eine Diskussion, was gibt es eigentlich an der Distributed Issue Tracking Front? Also ja, Issue Tracking dürfte jedem bekannt sein, der schon mal irgendwie was für ein Github gehört hat und so. Und was gibt es da eigentlich? Und dann haben wir da so ein bisschen rumgeguckt und so. Und es sind eigentlich zu dem Schluss gekommen, dass es da zwar schon einige Lösungen gibt, aber irgendwie sind die alle nicht so optimal und die sind auch alle schon etwas älter und kaum noch maintained und es war alles nicht so toll. Und dann haben wir ein bisschen überlegt, wie man das richtig machen könnte. Und ja, ich denke, du machst es da mal weiter. Echt? Ja. Ja, wir wollten irgendwas, was Distributed ist. Sprich, wo man Issues auch einfach von A nach B übertragen kann. Das Problem ist, wenn man hier irgendwie mal den Fehler gemacht hat auf SourceForge, irgendwelche Projekte zu veröffentlichen in den letzten fünf Jahren, dann wird man oder auf Google Code, dann wird man irgendwann mal die Problematik reingerannt sein, dass man da diesen schönen Issues, Gedöns, Funktionalität genutzt hatte, die dann aber faktisch tot war. Und dann gibt es Projekte, zum Beispiel Supertax, das ist so ein Super Mario-Klon, die hatten irgendwie, zeigt gleich mal drei verschiedene Issue-Tracker, die natürlich nicht miteinander gesünkt waren. Es war alles mehr als beschissen, wenn man da irgendwie mal gucken wollte, woran die gerade sind, so aus Interesse und weil man irgendwie nichts mehr zu tun hatte. Dann war die Idee, okay, wenn man jetzt davon ausgeht, dass man Git benutzt und das ist eine große Voraussetzung, weil es gibt ja Leute, die auch andere Dinge benutzen im Moment noch. Und da könnte man doch irgendwas reinbasteln letztendlich, weil da hat man schon die ganzen Voraussetzungen, wie man kann Dinge von A nach B pushen, man kann Dinge sauber voneinander trennen, man hätte ja Objekte, Blobs und was auch immer. Und das führt uns zum nächsten Punkt. Es gibt relativ viele Projekte, wie zum Beispiel Git Issues oder irgendwie so ein Google-Ding, die knallen erst mal Dateien ins Repo. Und das ist problematisch, weil im schlimmsten Fall liegen die halt im Tree zusammen mit dem Projekt, wo sie nicht wirklich reingehören, zumindest unserer Meinung nach. Und dann hat man halt diverse Probleme, wie zum Beispiel, okay, ich habe halt einen Namen, den ich belegt habe. Und wenn ich jetzt irgendwie zwei verschiedene Sourcen habe, also upstream und irgendwie so ein Entwicklungsklon oder so. Und ich will das irgendwie merchen wegen Kunden. Dann renne ich irgendwann wieder in Merchkonflikte rein. Und wenn ich dann hier irgendwie noch auf die Idee komme, Jason irgendwie reinzupacken, kann ich machen, aber dann habe ich halt andere Probleme, wie zum Beispiel, hey, ich habe einen Merchkonflikt bei irgendeinem Jason. Hey, ich habe einen automatischen Säuber, der wird das vorzusucht zu resolven. Hey, der macht mehr kaputt, als er eigentlich hilft. Säuber, ja, Mailing-List sind ganz toll. Da läuft auch relativ viel zum Beispiel Carle-Mailing-Liste. Hat wahrscheinlich jeder hier schon mal reingeschaut irgendwie. Da gibt es Patch-Sets, die irgendwie von A nach B wandern. Da gibt es Leute, die sagen, hey, ich habe hier einen Back gefunden. Ja, gucken wir mal, was da läuft. Es gibt auch automatische Tools, die da irgendwie Dinge bauen, feststellen, da sind Dinge kaputt und dann Leute notifizieren mit hey, hier, Backtrace, was auch immer. Ja, dann gibt es immer noch so Sachen wie GitHub und Bitbucket, die auch irgendwie Issuesysteme haben. Der will man optimalerweise auch irgendeine Form von Integration oder zumindest die Möglichkeit, irgendwie eine Integration zu stricken. Ja, und dann haben wir noch andere Anforderungen, an die wir uns teilweise irgendwann mal erinnert haben. Skrippbuckheit war auch ziemlich wichtig, weil Konsolenchunkies und irgendwie Adder hat auch mal irgendwie angefangen, Fett irgendwelche Skripte zu machen, weil er zu faul war, irgendwie Branches einzeln zu rebasen und Zeug. Und da war die Idee, hey, lasst mal so machen, dass man das auch mit Bash oder Fisch oder Lieblingsschell irgendwie erweitern kann. Ja, und es sollte auch irgendwie cool sein, also was auch mal das heißen mag. Ja, und das führt uns letztendlich zu der Projektidee. Genau, und die haben wir GitHub genannt. Aus der Projektdoku erstmal haben wir uns Issue Checking vielleicht nicht ganz so konventionell definiert. Issue ist im Endeffekt für uns erstmal irgendein Belangen, irgendeine Angelegenheit, die mit dem Projekt zu tun hat. Das sollte man im Folgenden einfach ein bisschen im Kopf behalten. Genau, da zählen dann natürlich Feature Requests dazu, ist klar irgendwo ein Issue, Bug Reports auch, aber auch Pull Requests und irgendwie Patch Sets, die da irgendwie mit zu tun haben. Genau, was ist drin in so einem Issue? Im Endeffekt ein Stück Fleece Text, wie wir das alle von der E-Mail kennen und so ein bisschen Metadaten, also irgendwie ein Auto natürlich, der das Ganze geschrieben hat und auch irgendwie eine Form von Status, irgendwelche Annotationen eventuell noch. Da kann man sich beliebig was stricken, wie man das haben möchte. Aber wir haben auf alle Fälle unstrukturierte Daten, also Fleece Text und in irgendeiner Form strukturierte Daten. Genau, und bei einem Patch Set und einem Pull Requests natürlich noch Änderungen, die da auch noch mich reinspielen, klar. So, jetzt ein ganz kurzer Exkurs, wie geht funktioniert? Im Endeffekt ist es total einfach von dem, was wir brauchen. Wir haben, die grünen Punkte sind Comets, die natürlich immer auf das vorherrige Referenzieren oder auch auf mehrere vorherrige und die Referenzieren immer auf einen sogenannten Tree. Und ein Tree ist, wie der Name schon sagt, ein kleines Bäumchen, das entweder auf andere Trees zeigt oder eben auf Blobs und die Blobs enthalten dann das, was im Endeffekt im Repo ist, also unsere Dateien. Genau, und das machen wir uns zur Nutze. Genau, wir haben nämlich überlegt, so eine Nachricht, so ein Issue ist im Endeffekt ein Comet ohne ein Tree hinten dran. Also im Endeffekt ein Comet, das nur eine Nachricht enthält. Und schon haben wir jede Menge coole Sachen, mit denen wir richtig gut umgehen können und das ermöglicht uns zum Beispiel den Nachrichtenbaum an Referenzen aufzuhängen. Genau. Und die Kopfreferenz ist praktisch der upstream Status, also von dem öffentlich zugänglichen Projekt. Genau, daraus ergeben sich, wie gesagt, jede Menge Vorteile für uns. Der erste Vorteil, den wir auch vorhin schon praktisch genannt haben, was die anderen Tools machen, wir haben keine Dateien im Repo für unsere Issue Checking. Das Issue Checking passiert praktisch in Git, komplett in Git, im Repo selber sieht man das erstmal nicht an. Also wenn ich meinen Checkout habe, meine lokale Kopie, dann liegen da ganz normal meine Sourcefiles rum oder was auch immer ich damit tracken will. Wir können natürlich offline arbeiten, das dürfte bekannt sein. Jeder, der schon mal mit Git gearbeitet hat, wird das irgendwann lieben lernen. Und wir haben natürlich keine Merchkonflikte, da wir ja eben keine Dateien haben. Was dazu führt, wir brauchen nicht unbedingt eine lineare History für die Issues. Wie gesagt, das sind Bäume abbildbar und dementsprechend auch Mailing Liste. Also so ein Thread aus einer Mailing Liste ist im Endeffekt ja auch nur ein Baum. Und das war auch unsere initiale Anforderung, die damit praktisch schon von Haus aus abgedeckt wäre. Genau. Und wir können natürlich, wie vorhin schon gezeigt, einen Comment kann man auf mehrere andere Comments zeigen. Wir können auch andere Comments referenzieren und dementsprechend auch Diskussionen merken. Wer schon mal auf GitHub erlebt hat, bei größeren Projekten kommt es ab und zu vor, dass ein Bug Report mehrmals eingetragen wird oder von jemand eingetragen wird, der noch auf einem älteren Stand ist von dem Projekt, der eigentlich schon längst gelöst wurde, der Bug oder ein Feature Request, der mehrmals eingepflegt wird. Und wenn dann die Maintainer eins von diesen Issues zu machen, ohne auf ein anderes irgendwie zu referenzieren, wie haben wir schon gemacht oder so, dann bekomme ich keine Notifications mehr von GitHub, praktisch wenn auf dem anderen Issue noch irgendwie Diskussion läuft oder so. Das lässt sich hier durch sehr einfach abbilden. Genau. Wir wollen es nicht verheimlichen, es gibt auch ein paar Nachteile. Zum Beispiel sind Comments nicht enderbar, beziehungsweise wenn sie erst mal gepublished sind. Deswegen gibt es halt so Dinge, wie ich fixe meine Tippfehler im Nachhinein, gibt es natürlich nicht. Und was da eben noch alles mit dran hängt. Und man legt relativ viele Comments im Repository an. Nehmen wir an, wir haben ein Hobby-Projekt mit, sagen wir mal, 2.500 Comments. Und wenn wir jetzt da praktisch das Issue-Tracking ins Repo mit reinnehmen, dann werden wir das halt gleich mal mehr, weil für jede Nachricht wird ja wie gesagt ein Comment angelegt, dann kommt man halt auf stoppel des Dreifache, wie auch immer. Und das kann eventuell dazu führen, dass manche Tools etwas schwerer zu bedienen sind. Ich verwende persönlich gar einen Tick, das ist ein Kommando-Zeilen-Cursus-Frontend, das so ein bisschen Visualisierung macht von dem Git Repository. Und da liegen dann halt plötzlich sehr, sehr viele Comments rum. Und da man wie gesagt auch Diskussionen merken kann und so, liegen auch viele Merch-Comments rum. Und dann wird das alles ein bisschen schwieriger visuell nachzufolgen sein. Lässt sich allerdings anpassen und konfigurieren, müsste man dann eben vornehmen. Ein klarer Nachteil. Genau. Und Sachen, die noch so Inconveniences sind, sind auf Implementierungsebene. Wie schon gesagt, Incommit ist nicht enderbar. Deswegen müssen so Statusänderungen oder so Metadatenänderungen wie Text oder Labels müssen aggregiert werden auf der Implementierungsebene. Das kann man als Inconvenience ansehen. Je nachdem, wie viel da zu aggregieren ist, könnte es auch etwas länger dauern. Aber das nehmen wir in Kauf. Und auf Nutzebene natürlich braucht der Nutzer, um seine Issues zu veröffentlichen. Also so ein Issue zu feilen oder ein Bug Report zu feilen, muss es irgendwie öffentlich stellen können, damit die Entwickler das praktisch ins Main-Report ziehen können. Das heißt, er braucht irgendwo Push-Rechte auf den Repository. Und im Endeffekt die ganze Geschichte um Autorisierung und Authentifizierung. Da haben wir uns aber für das Projekt selber gesagt, das ist kein Problem, was wir lösen wollen mit dem Projekt. Wir können das Projekt auch mit Tracking in slash mit geht lösen und nicht irgendwie Distributed Authentication oder so was. Genau. Sonst die schöne Eigenschaften ist, wir haben natürlich Wahlfreiheit für das Report, wo die Issues drin liegen. Was heißt, ich kann natürlich mein Projekt haben und meine Issues da drin tracken mehr oder weniger. Ich kann allerdings auch ein extra Report nur für die Issues von meinem Projekt aufmachen. Und dann so Geschichten machen wie jedes Mal wenn Issues praktisch resolved ist oder wenn Feature Equest praktisch implementiert ist, kann ich die Comments in mein Development Repository übernehmen oder ich kann mehrere Repositories haben für Arten von Issues. Da ist man ziemlich flexibel dann damit. Genau. Und man kann natürlich auch mehrere Projekte in einem Issues Repository tracken etc. Und was auch noch so eine Anforderung war, wie gesagt, wir sind so beide Solenchunkies. Wir wollen eine Command-Line Interface-Applikation, die im Endeffekt wie Git zu benutzen ist und immer One-Shot-Commands sind. Im Endeffekt ist es so, dass es sogar ein Git Sub-Kommando ist. Also unsere Kommandos fangen auch alle mit Git praktisch an. Nämlich Git-Dit für Distributed Issue Tracking. Genau. Und jetzt macht der Jule mit der Entwicklung weiter. Ja, also Implementierungssache war ein neues Projekt gewesen. Uns ist relativ spät aufgefallen, dass es dieses Tool schon gab, dass wir ursprünglich machen wollten. Sprich irgendwie Mitte, Ende November musst du ein neues Projekt her und dann sind wir halt auf die Idee gekommen und haben damit angefangen. Und es ging darum, Sachen möglichst schnell zu lösen. Was bedeutet hat, wir haben meistens manuell Dinge gemacht und im Production-Report rumgefuscht haben wir Plumbing-Commands in Git und Issues angelegt. Was auch schon mal zeigt, dass das Datenformat nicht mal so beschissen gewählt ist. Weil wir haben keinerlei Library für JSON oder sonst irgendwas gebraucht. Sondern wir konnten letztendlich mit Git eigenen Plumbing-Commands, also Low-Level-Kommandos und Programmen was machen. Im Nachhinein haben wir letztendlich Bash Script geschrieben, um das zu automatisieren, was wir endisch gemacht haben in dem Moment. Nachdem wir erstmal überlegt haben, was wir eigentlich gerade getan haben. Ja, die Architektur, die dann irgendwann gewachsen ist, waren letztendlich einzelne Tools, die irgendwelche Dinge tun mit einem passenden Namen, so dass man die schön über Git und so ein Metacommando namens Git-Dit ausführen konnte. Sprich, das Ganze war ähnlich wie Git selbst, was wir ja wollten. Und so mehr oder weniger im Nachhinein hat sich eben auch bei uns diese Unterscheidungen in Plumbing und Porcelain also in Low-Level-Kommandos, die zum Beispiel Nachricht anlegen und High-Level-Kommandos wie hey, mach mir neues Issue oder beantworte auf diese Nachricht irgendwas ergeben letztendlich. Und hat sich auch sogar schön abgebildet in den Namen. Das sieht man hier. Die Porcelain-Kommandos, die man letztendlich als Endnutzer benutzt, was letztendlich die Minus, kann man durch die Leerzeichen ersetzen. Und das ist ein Wort für das, was man machen will, während man auf der anderen Seite, auf der Plumbing-Seite, ja, man sieht es, etwas längere Namen. Man muss sagen, wir haben dann irgendwann nachrasportiert. Das hat sich aus ein paar Gründen ergeben und es ist dann irgendwann gekommen, okay, da sind, na ja, es gibt viele Best-Script, die viele Dinge tun, die Leute nicht wollen und da wollten wir nicht unbedingt reinrennen. Dass jemand mit einer speziell gekrafteten Message Nutzer-Schaden zufügt und sein Reh-Programm legt. Komplexität ist halt auch so eine Sache, weil wir haben für, wir haben hier angefangen zum Beispiel für Metadaten zu extrahieren aus Nachrichten und das war dann zwar nur irgendwie ein paar Zeilen AWK, aber ein paar Zeilen AWK, für die man schon Kommentare gebraucht hatte. Und das zeigt schon, okay, es ist ein bisschen komplexer. Das heißt, machen wir lieber irgendwie in einer Programmiersprache, wo man gescheite Literaturen und Zeug hat. Auch so eine Sache war, dass wir eine Api wollten, ohne irgendwie nach Haufen Exek-Calls auf irgendwas zu machen und wo man dann eventuell auch so etwas wie Typ-Sicherheit hat, was ja auch ganz toll ist. Warum Rust? Ich habe schon gerade gesagt. Security-Typ-Sicherheit und weil es unserer Meinung nach kein fünffiges C++-Binding gab, das wäre die alternative Alternative gewesen. Es gibt zwar so ein QT-Binding, aber wollten wir uns nicht ans Bein binden. Wir sind beide, also ich komme aus der C++-Schiene, im Moment eher aus der Rust-Schiene und wir können beide beides so mehr oder weniger. Und da dachten wir, okay, nehmen wir irgendwas, was wir können, da müssen wir nicht irgendwie doch mal neu lernen. Ja, wir haben letztendlich die Arbeit, die wir für die Bash-Script gemacht haben, mehr oder weniger wiederholt mit der Ausnahme, dass wir jetzt interpretieren mussten, weil die Kommentare auch nicht mehr so eindeutig gestimmt haben teilweise. Wir haben Rust-Binary, das als Metacommentor steht und die Subcommands liegen da halt irgendwo drin als Funktion. Wir haben eine Library gestrickt, die letztendlich die Core Funktionalität hat und das Binary soll letztendlich nur ein Binding machen. Auf die Library ist ein bisschen komplexer, weil das macht halt auch so Sachen wie wir das Zeug in eine künftige Form bringen und Zeug, aber das ist es letztendlich. Und dann haben wir angefangen, einzelne Subkommandos zu portieren. Was interessanterweise darauf rausgelaufen ist, dass wir wunderbarerweise das Tool weiter nutzen konnten, während wir irgendwie portiert haben und keinen harten Switch machen mussten. Ein paar von den Porzellan-Kommandos von den Plumbing-Kommandos gekostet, weil man die einfach nicht mehr gebraucht hat und die auch keinen Sinn mehr ergeben haben. Wie zum Beispiel Argumente für irgendein anderes Bash-Skript vorbereiten, ist halt komplett weggefallen. Wir haben geguckt, dass wir die Funktionalität, die wir in den Bash-Skripten haben, teilweise auch aus Bash-Limitierung erhalten, einfach damit wir das Ganze 1 zu 1 übertragen haben. Mit ein paar Ausnahmen, zum Beispiel haben wir jetzt Long-Options in unserer Rust-Implimentierung ein paar Funktionalitäten sind jetzt so nicht direkt 1 zu 1 übertragbar gewesen. Das heißt, man hat da auch ein paar Abstriche gemacht, einfach um voranzukommen im Moment. Ja, und damit sind wir fast fertig. Wir haben noch ein Kommando offen. Git.Show, mit dem man sich so ein Issue anzeigen lassen kann mit allen Nachrichten. Das war ursprünglich auf Git.Show implementiert, letztendlich als Rapper, der irgendwie da drauf zugreift. Und ja, da sind wir gerade im Moment noch dran. Das ist fertig zu machen. Ja, was geht? Wir können Issues anlegen, auf Nachrichten antworten. Wir können das Ganze listen und anschauen, wenn man zumindest in ein Branch verwendet, wenn nicht, dann hat man halt noch das Bash-Skript. Und ok, Tippfehler, Metadaten, setzen Abfragen, was letztendlich darauf rausläuft, dass wir Trailer, die man vielleicht schon mal gesehen hat, wenn man LKML oder so gelesen hat. Das sind letztendlich kleine Texte am Ende von der Commit-Message. Ja, auf einfache Art und Weise manipulieren kann. Im Sinne von, ich klatsche die unterne neue Nachricht unten drunter. Und wir können pushen und fetchen. Allerdings nur im Moment, wenn der Fetsch darauf rausläuft, dass ich keine Authentifizierung brauche und ansonsten halt ein SSI-Action am Laufen habe, weil wir zuvor waren, Authentifizierung zu machen, was nicht SSI-Action ist. Was nicht automatisch geht, ist, was wir ursprünglich vorhatten, aber auch in dem Bash-Skript nicht ging, war Garbage Collection. Wir haben gesagt, dass wir die Nachrichten in einem Issue an Referenzen aufhängen. Irgendwann ist eine Referenz nicht mehr notwendig, wenn zum Beispiel jemand auf dann die Nachricht wiederum geantwortet hat. Die werden noch nicht automatisch abgeräumt. Das ist halt ein bisschen blöd, aber da war für uns jetzt noch keine Notwendigkeit, weil wir jetzt nicht so über viel Traffic hatten. Subscriben war die Idee, wir haben das teilweise manuell gemacht, dass wir in unserer Git-Konfig nochmal einen RevSpec angelegt haben. Das ist letztendlich ein String, der sagt, hey, hier auf dem Remote-Repo liegt an der Stelle irgendwelche Referenzen, die du lokal irgendwie so mapen kannst und dann kann man einfach mit Git Push oder Git Pull oder Git Fetch automatisch dann auch die Issues updaten und das ist ganz praktisch, ist aber noch nicht automatisiert. Dann sowas wie amenden, das heißt, dass solange ich eine Nachricht noch nicht gepusht hab oder solange noch niemand drauf geantwortet hab, kann ich die noch ändern. So einer Logo zur E-Mail, wenn die E-Mail raus ist, dann kann ich die auch nicht mehr ändern, aber solange sie halt noch in meinem Outbox oder was auch immer das heißt noch manipulieren, ohne dass es irgendjemand merkt. Wie schon gesagt, die Authentifizierung bei Push und Fetch ist halt ein bisschen blöd im Moment und die relativ wichtig eigentlich war noch, dass wir Issues filtern, weil in der Regel interessieren ein Issues, die vor drei Monaten schon geschlossen wurden, nicht mehr, aber die, die irgendwie vor zwei Tagen geöffnet wurden, das bringen uns zu den nächsten Schritten. Als erstes steht die Port abschließend. Bei der Dokumentation nachbessern Tests haben wir jetzt auch noch nicht ganz so viele, bis keine und dann erstmal Release machen, damit wir das, was wir haben an Funktionalität, erstmal so geplantelt haben. Und dann geht's darum noch ein bisschen Refactorn, weil ja, wir haben nicht, ja, es sind noch ein paar Feinheiten im Code drin und dann geht's Richtung Features was bedeutet, wie zum Beispiel Subscriben, Gabschkollekten aber auch so schöne Sachen wie dass man Issues in Kategorien einteilen kann, so dass man dann zum Beispiel im End haben Issues eine ID, das ist letztendlich ein Share1-Hash und das ist relativ blöd vor allem dann erstmal über alle durchgehen muss, um zu gucken was für ein Relevant ist, wenn man jetzt Kategorien macht, als es so ein Scope vorne dran, wie zum Beispiel Gameplay oder so für irgendein Spiel, dann ist schon mal klar, okay, ich hab hier eine Kategorie und weil das Ganze dann immer noch ein bisschen inconvenient ist, mit den 40 Zeichen langen Hashes, vielleicht mit Symbolic References die man von anderen Kontexteer kennt, vielleicht noch irgendwie mit einbauen, dass man die schön verwenden kann, um dann auf Issues oder einzelnen Nachrichten zu referenzieren, wenn man zum Beispiel so eine Nachricht mal durchliest oder ein Issues und dann hier irgendwas markieren will oder irgendwas folgen will und dann mal weiterschauen will, antworten oder so. Andere Sachen, die noch geplant sind wir haben vorhin gesagt, dass die Authentifizierung und Autorisierung das wir uns erstmal nicht auf die Fahne geschrieben haben, aber wir wurden darauf hingewiesen von jemandem, das ist eigentlich eine ganz tolle Idee wäre, wenn man so ein Helper für Serverseite gehux hat, so dass man sagen kann, okay, ich hab hier ein Remote-Repo und das akzeptiert einfach nur Pushes von jedem, aber ich filter halt nur intern die Sachen raus, die mir mein Repo nicht zerschießen, also ich akzeptiere letztendlich nur Issues und zwar neue Issues und keine Updates, die Issues, die anliegen irgendwie zerstören oder so und dann kann man da als Metainer einfach das Zeug hinschmeißen und jeder, der lustig ist, kann da schön drauf rum pushen und ich kann halt im Nachhinein dann entweder Issues moderieren oder sonst irgendwas machen nicht jeder Nutzer hat Git auf seinem Rechner deshalb war auch die Idee okay so ein Web-Interface war toll, aber nicht in dem Projekt, weil das wäre eindeutig was anderes und irgendwie Integration wie zum Beispiel Mailing-Liste oder GitLab, GitHub, was auch immer ja, dass man da schön irgendwie zeigen kann hier die Issues da hin oder eben die Issues irgendwie übertragbar macht was da auch noch mit reinläuft, ist halt so Sachen wie Import-Export-Funzilität von Issues die jetzt auch nicht unbedingt in das Projekt mit rein muss also das einzige was wirklich das Projekt selber betreffend sind, die serverseitigen Hooks damit wären wir durch ihr könnt euch das anschauen es ist wie schon gesagt noch nicht, also man kann's zwar benutzen, aber es hat halt noch nicht die Reife die man vielleicht haben will für ein Projekt und ja, aber mit Rumspielen kann man schon mal, wenn man irgendwie ja Bock drauf hat da werden wir einfach durch also wenn ihr Fragen habt, gerne ja, ich glaube ich fahr da aus Mikro oder ah, okay ja, ich wurde für eine Live-Demo aufgefordert, ich hab hier schon mal eine schöne Schelle für Leute mit kleinen guten Augen haben vorbereitet und dann kann man hier zum Beispiel Issues listen in dem Moment mit dem Format was nicht ganz so hässlich aussieht wo das Datum angezeigt wird die sind auch sortiert wirklich nach Datum und dann sieht man da schon mal was wir gemacht haben wir haben zum Beispiel irgendwann gemerkt, dass wir unsere beste Implementierung die Editor-Environment-Variable irgendwie als harte Dependency hatten und dann kam halt irgendwie ein DB das erstmal um die Ohren geflogen ist und dann dachten wir, ja, sollte man vielleicht ändern andere Sachen die die reingekommen sind wie zum Beispiel das älteste Issue, das wir haben das sogar älter ist als die ersten irgendwie Skripte, die im Repo liegen hey, wir brauchen irgendwas um Issues und Comments irgendwie zu verfassen als Skript als Automatisierung da können wir auch mal gleich reinschauen vielleicht noch mal nur zum Verständnis also dieser SHA1, der da steht den generieren wir nicht, den generiert geht im Hintergrund also wir benutzen da alles was Git so uns liefern kann das heißt, wir haben da nicht irgendwie irgendwelche Dinge, die im Hintergrund noch pausen oder Zeug machen, sondern das sind im Endeffekt wirklich nur Comments, die wir halt von Git uns holen und entsprechend filtern also nur Comments, die uns hier fürs Issue-Tracking interessieren und nicht irgendwie was im Repo halt passiert und wenn man sich jetzt so ein Issue anzeigen lassen will dann macht man das Ganze mit dem Hash Moment hab ich's kaputt gemacht? ich hab's kaputt gemacht, glaub ich blöd jetzt es sind auch ein paar andere Möglichkeiten okay, ich hab's kaputt gemacht ja, ich hab vorhin noch ein paar Änderungen gemacht das ist halt, wenn man irgendwie kurz vor der Live-Demo noch mit Romo spielt und irgendwie Code ändert, dann muss man damit rechnen das Ding nicht mehr tun aber wo bin ich? mit der alten Bash-Version die hier noch irgendwie rumfährt wieder funktioniert's auf jeden Fall da sieht man, wir haben hier ein Issue aufgemacht mit irgendwie so einem Status-Tag am Ende und haben das dann irgendwann eingeführt und haben das dann geschlossen jetzt kann man auch mal kurz schauen wie das dann aussieht dann so macht ja, das geht natürlich nicht ja, stimmt auch wieder, aber die müsste als Live noch irgendwie auftauchen machen wir mal kurz ja, da haben wir zum Beispiel so sieht das letztendlich aus, das ist halt das Problem was wir vorhin angesprochen haben wenn man halt viele Issues hat, dann hat man in seinem Tool irgendwie so ganze Literreien von irgendwie Referenzen, die einem nicht unbedingt versagen und das sieht man auch schön so die Idee wir haben hier Headreferenzen und Leaves der Hash von dem Leaf ist auch der Message selber, das ist nichts anderes als die Commit ID wie man jetzt hier schön sehen kann dass der Short-Hash derselbe ist wie der Lang-Hash und wenn wir dann halt sagen okay, wir haben jetzt hier irgendwie ein Status erreicht den wir upstream jetzt akzeptieren haben oder so, wie zum Beispiel wir haben eine Status-Änderung dann setzen wir die Headreferenz dann hier auf die Antwort, die sagt wir haben das geschlossen jetzt habe ich aber noch einen anderen schönen Beispiel gesucht wo man das schön sieht ah ja, hier, schön hier sieht man wie das aussieht wenn man jetzt sowas aus dem Main-Repo referenziert, das hier ist ein Issue wenn man das so betrachtet machen wir es mal als dann sehen wir hier auch dass es eine Unterhaltung war ich suche hier gerade noch der Option können wir auch schöne Grafen anzeichnen was in dem Fall relativ langweilig ist dass wir hier irgendwie gesagt haben okay, wir brauchen irgendwie eine Funktionalität um irgendwie Issues und Comments automatisiert zu machen haben wir dann rumdiskutiert von wegen wie machen wir das Blah, erster Draught und Blah dann ist irgendwie im aufgefallen Ja, das ist gar nicht so toll wie man das hier referenziert oder so und wenn man sich jetzt zum Beispiel das hier anschaut dann sieht man auch den schönen Vorteil davon, weil das hier letztendlich hier fest referenziert ist das hat den Vorteil oder auch Nachteil je nachdem wie man das sieht wenn man sowas macht dann ist auch sichergestellt dass alles was zu dem Issues dazugehört sprich aber auch Referenzen auf den Code, wenn man das dann so referenziert mit in das Issues Repo ist das heißt, wenn man irgendwie ein Issues Repo hat und dann irgendwie so referenziert auf irgendwelche Bugs dann ist auch klar der Stand definiert und dann kann man einfach ja, da muss man nicht irgendwie noch rumsuchen, sondern man kann einfach sagen okay, guck mal auf die Referenz, die da referenziert ist da wird Tooling auch nicht ganz schlecht aber ist noch nicht gemacht ja wir haben hier nee, Moment ja, okay das ist der Feld den ich gerade eben gemacht habe die Dokumentation ist gerade auch ein bisschen sperrlich ja, hier sieht man noch eine Auslösung von den porzellellen Commanders und was die eigentlich tun ja also, ich will jetzt ehrlich sagt nicht irgendwie in dem Production Repo rumfuschen, in dem ich das Issues aufmache, aber man kann sich glaube ich vorstellen, wo es hingeht bei gtdnew passiert eigentlich dasselbe wie bei einer normalen wenn man irgendwie ein Command anliegt, da geht erstmal der Editor auf, den man irgendwie konfiguriert hat dann kann man da seine Nachricht rein tippen und das war es bei Reply genauso, mit dem Unterschied dass er dann eben noch irgendwie so ein Reply Subject in die Datei knallt, bevor der Editor aufgeht und so was irgendwelche konkreten Wünsche was ich jetzt noch zeigen soll oder so oder Bandeforten ich habe noch nicht verstanden wie die Commits auf die Objekte verweisen auf diese sich beziehen weil der Commit den ihr gerade gezeigt habt, der hatte ja 2 Parents aber er hat, nachdem wie ich es verstanden habe, müsste er eigentlich 3 haben nämlich den vorigen Commit den vorigen Nachricht im Thread und der Baum auf den er sich bezieht ja also ich habe hier normal Gejo benutzt und da wird es nicht unbedingt angezeigt man kann sicherlich auch irgendwie raus kritzeln von dem wie der ist, aber der hat letztendlich 3 solche Hashes und der dritte zeigt auf den Tree und im Fall von dem Empty Tree ist der letztendlich der SHA1 Hasch von der Lernmessage woher weiß geht es dann, ob das ein Merch-Commit ist oder ob das ein Commit ist, der sich auf ein voriges Issue bezieht im geht achso wir haben letztendlich eine Regel eingeführt irgendwann wenn es darum geht ob zum Beispiel eine Nachricht zum Issue gehört oder zu welchem die Nachricht gehört folgen wir wirklich nur dem ersten Commit das heißt dem ersten der hier in der Liste auftaucht und weil wir eben hier den Hasch von der initialen Nachricht haben können wir auch selbst wenn wir in der ersten Nachricht wenn das ein Buck Report zum Beispiel ist schon auf irgendeinen Stand verweisen sagen okay wir haben hier eine Referenz die den selben Hasch enthält wie der Hasch von dem Commit selber und wir sind dann okay das ist eine initiale Nachricht und dann können wir für jede Nachricht so zurückverfolgen letztendlich zu welchem Issue das gehört falls das deine Frage war und die Referenzen sind dann letztendlich optional alle und werden auch für solche Zwecke nicht verfolgt sondern das sind dann wirklich reine Referenzen auf Sachen die nicht unbedingt was mit dem Issue zu tun haben müssen das ist eine von den Nachrichten selber sonst noch Fragen werden die Status Informationen der einzelnen Issues irgendwo zusammengefasst dass man sich also zum Beispiel anzeigen lassen kann eine Liste von allen Issues die zum Beispiel noch offen sind oder wir haben keine Aggregation also Voraggregation sondern du musst das wirklich letztendlich die Issues im Moment noch abgrasen und dann letztendlich schauen für jede wie der Status ist und dann die Rausfiltern die geschlossen sind es gibt wir haben uns zwischendrin glaube ich mal überlegt wie man das irgendwie gescheit machen kann aber es sind dann auch zu keinem Ergebnis gekommen wo wir gesagt haben ja das ist es aber wir sind für Vorschläge offen und ja eine Möglichkeit wird zum Beispiel dass man irgendwie spezielle Referenz macht die immer geupdatet wird mit irgendwie dem neuesten was was gerade da ist das ist halt noch mehr Neues im Repo die Frage ist halt ob man das haben will oder nicht aber wie eine Möglichkeit zum Beispiel okay dann vielen Dank dass ihr hört wart wenn ihr Bock habt schaut es euch an ja habt Spaß