Der Schwarm!

Mir fällt leider kein vernünftiger Titel ein: Unter dem Namen Ruby Swarms: Visualizing Rails & Git beherbergt igvita.com einige sehr interessante Visualisierungen von Coding-Aktivitäten. Sehr sehenswert!

Einen Git-Branch löschen?

Da schreibe ich gerade noch, wie praktisch es bei Git ist, einfach einen Teil des Repositories als separates Projekt herauszulösen, und dann das: Ein zum Hochschieben der Tags abgesetztes git push --all schiebt alles, was im lokalen Repository ist, auf den github, darunter auch das komplette alte Projekt, aus dem ich das Teilprojekt gerade erst herausgelöst habe. Wie peinlich.

Jetzt gibt es zwei Fragen: Warum tauchen plötzlich die alten Commits wieder auf, und wie werde ich sie wieder los?

Die Antwort auf die erste Frage ist leicht: Der alte Branch war nach dem Zurechtschneiden immer noch in dem Repository vorhanden, das früher einmal das Monsterprojekt beherbergte. Er war nur eben abgehängt. Normalerweise war der Branch nicht sichtbar, und da nach den Anweisungen von github vom frisch geglaubte Projekt mittel git push origin master explizit nur den master-Branch hochgeladen wurde, fiel nicht gleich auf, welches Problem da noch wartete: Das remote Repository war tatsächlich schlank, das lokale Repository aber nicht.

Den Schlammassel lokal wieder loszuwerden ist dann doch nicht einfach. SCMs sind sehr gut darin, sich Sachen zu merken, und nicht sehr kooperativ, wenn sie etwas vergessen sollen -- Git ist da keine Ausnahme. Kurz, ich habe ewig probiert, und nichts hat geholfen. (Letztlich sollte es helfen, alle Referenzen auf die ungewollen Commits zu entfernen. Also alle Branches und Tags löschen, die dahin zeigen.) Viel wichtiger ist natürlich, die ungewollt hochgeschobenen Daten vom github wieder zu löschen.

Die Lösung ist allerdings verblüffend einfach: Zuerst werden die ungewollten Objekte (Tags und ggf. Branches) auf einem remote repository (z.B. github) gelöscht, dann wird von da ein frischer Clone gezogen:

# tag "stoertMich" und branch "obsolete" loswerden

git push origin :stoertMich

git push origin :obsolete

# irgendwohin, wo der frische Clone aufwachen soll

cd ..

# ...und frisch clonen

git clone

Die Seite, der ich diese Einsicht verdanke, ist, verglichen mit den Ausmaßen des Problems, irritierend schlicht: github's Guide: Remove a remote branch. Allzu leicht übersieht man die Doppelpunkte, die praktisch die Lösung des Problems sind. Ich habe sie daher mal rot eingefärbt.

Ein kurzer Blick in die Packs (unterhalb von .git) verrät, daß da kein uraltes, gigantisches Monster mehr schlummert, sondern nur ein schlankes, blankes Repository mit dem exakt herausgelösten ehemaligen Teilprojekt.

Und wieder gerettet.

Git Ready!

Git ist das Nächste Große Ding zum Thema SCM, das ist offensichtlich. Noch ist zwar Subversion das Maß der Dinge, wenn es um populäre SCM-Systeme geht, ist aber schon lange nicht mehr unangefochten: Git hat die Linux-Entwickler und eine eindrucksvolle Gemeinde von Ruby (on Rails) Entwicklern auf seiner Seite. Wer mit RoR entwickeln will, braucht mittlerweile Git, und wer Git hat, braucht kein Subversion -- kann es aber weiterhin benutzen. Embrace and, äh, wie hieß das noch? Will Linus die Weltherrschaft? Mein Gott, erwartet uns hier ein neuer Flamewar?

Genug der Vorrede, frisch vom github kommt die Empfehlung für git ready, wo ab sofort täglich Informationen zu Git versprochen werden.

Was haben die Römer...

Ok, mir ist klar, daß jederman selbst auf YouTube danach suchen kann, aber sei's drum, ich will dieses Video einfach hier reinhängen:

Dabei sei gesagt, daß Monty Python einen Sack voll Sketche auf YouTube veröffentlicht (für den Fall, daß das noch nicht bis in alle Winkel dieses Planeten vorgedrungen ist). Ja, genau! Jede Menge Monty Python, direkt von Monty Python, mit dem Segen von Monty Python! Das ist er, der Grund, weshalb ich mein Modem gegen eine DSL-Leitung eingetauscht habe. (Na ja, das ist jetzt vielleicht etwas zu dick aufgetragen...)

Wie dem auch sei, empfehlenswert ist der Monty Python Channel auf jeden Fall.

Kann Dein SCM das?

Vor einer kleinen Ewigkeit, als ich noch dachte, CVS sei die beste Erfindung seit geschnitten Toastbrot (hey, ich war jung und brauchte das Geld für andere Sachen, z.B. Toastbrot!), habe ich begonnen, meinen selbstgeschriebenen Code in CVS Repositories einzuchecken. Leute, die mich damals kannten, hielten mich für, na ja, ein bißchen komisch, weil ich Sourcecode aufgehoben habe, der schon lange aussortiert war, aber ich bin sicher, sie haben heute andere, ganz neue Gründe dafür.

Aber das tut nichts zur Sache. Der Server ist schnell aufgesetzt, und so füllte sich das Repository mehr und mehr mit Daten. Dann fanden auf einmal alle Leute CVS ganz toll, also dachte ich mir, es wird Zeit, zu Subversion zu wechseln, bevor alle denken, ich wäre, na ja, nicht mehr komisch genug.

Gesagt, tun, getan. Bei der Gelegenheit habe ich dann entdeckt, daß ich in all den CVS-Jahren nur einen einzigen Branch angelegt habe, und den auch nur, um das mal zu probieren. Im Nachhinein hat sich das als gute Idee herausgestellt. Also, nur einen Branch zu verlieren, meine ich.

Aber Subversion macht alles besser, ich konnte das Repository leidlich gut importieren, und in Subversion kann man prima branchen. Und taggen. Und viele andere Dinge. Eine ganz neue SCM-Euphorie bemächtigte sich meiner, und ich fange an, Projekte zu bauen, nur, um irgendwas in Subversion zu importieren, zu branchen und zu taggen. Interessanterweise bin ich extrem selten zum branchen gekommen, und ich kann mich an keine Merges erinnern. Hängt wohl mit der gewöhnungsbedürftigen Semantik von Subversion zusammen. Aber ich will nicht undankbar erscheinen: Für Projekte, in denen man weder sinnvoll branchen noch sinnvoll mergen kann (also z.B. bei der Versionierung von Bildern), kann ich mir vorstellen, auch nochmal Subversion zu benutzen.

Und schließlich kam der Moment, den alle Subversion-Verwalter ab dem zweiten Aufruf fürchten: Das Repository wird unhandlich groß, und man entscheidet sich, es aufzuteilen. Selbstredend soll die History erhalten bleiben.

Die Idee ist einfach: Im Repository projekte liegen fünf Projekte project_uno, duo_twin_double, triproj, quadra und p5 friedlich nebeneinander, jedes soll jetzt in ein eigenes Repository. Gründe für diese Aufteilungen finden sich immer, deshalb verzichte ich auf die Aufzählung. Aber wie schneide ich aus einem Subversion-Repository einen Zweig Objekte?

Na ja, ich will's nicht schwierig machen: Es geht nicht. Die innere Struktur von Subversion erlaubt das Ausschneiden von Subtrees offenbar nicht. Irgendwo habe ich dann gelesen, daß aufgrund der inneren Struktur der Werte im Zusammenspiel mit dem mechanischen Aufbau der Physik die Beobachtung zu machen geht nicht. (An der Stelle habe ich Kopfschmerzen bekommen und aufgegeben.)

Szenenwechsel. Unser Subversion-Repository wird links auf einer Liege von der Bühne geschoben, überall rote Tinte, die Krankenschwester füllt ein Formular aus und guckt auf die Uhr, Auftritt git im schwarzen Rollkragen-Armani-OP-Kittel als jung-dynamischer Chefarzt (ohne Vorhang, wir haben's eilig). Kurzer Blick auf den Patienten, Organisation der Operation in die Phasen Zurechtlegen, Zuschneiden und Zumachen, und etwas Beeilung bitte, der nächste Patient wartet schon, das kann ja nun wirklich nicht so schwer sein. Der Patient bekommt ein Sedativ, und los geht's.

Zurechtlegen: In unserem Szenario haben wir fünf Projekte in einem Repository. Das wird erstmal kopiert:

# ~/projekte/ > cd ..

# ~/ > git clone projekte p1

Checking out files: 100% (1930/1930), done.

# ~/ > cd p1

# ~/p1/ >

Intermission: Es sei bei dieser Gelegenheit ausdrücklich festgestellt, daß dieser Schritt wirklich extrem wichtig ist. Wir haben vor, alles bis auf ein Unterverzeichnis aus dem Repository unwiederbringlich zu löschen. Mit anderen Worten: Alles außer dem Verzeichnis, was wir im nächsten Schritt auswählen, wird gleich weg sein.

Stimme aus dem Off: Mach lieber eine Kopie mehr als eine zuwenig. Ehrlich. Bitte. Mach. Das. Sorgfältig. Und. Richtig. Nicht vergessen, wir reden hier von git: Schieb eine Kopie auf github, oder schick sie einem Kollegen, oder Deinem Bruder, oder Deinem Friseur, egal. Nur hab nicht im nächsten Schritt die einzige Kopie des Repositories unter'm Messer. Du würdest es bereuen.

Und weiter.

Zuschneiden: Ein Blick in das Repository verrät uns, daß wir es mit einer exakten Kopie des unter ~/projekte gespeicherten Repositories zu tun haben. Wir finden darin ein Verzeichnis project_uno, in das unsere fleißigen Entwicklerameisen emsig tonnenweise Code geschaufelt haben (natürlich haben wir selbst mindestens die Hälfte davon geschrieben, sonst dürften wir nicht so über unsere netten und geschätzten Kollegen reden). Aus diesem Verzeichnis project_uno machen wir jetzt ein eigenes Repository:

# ~/p1/ > git filter-branch --subdirectory-filter project_uno -- --all

(Meldungen von git hier, die abzutippen oder neu zu erfinden ich zu bequem bin, die der geneigte Zuschauer bei dieser Folge aber bitte genauestens zu lesen, zu verstehen und als nicht weiter kompliziert einzustufen hat.)

Genau, das war's schon. Ein einziger gekonnter Schnitt, und wir sind fertig. Schneller als ein Blinddarm, soviel ist sicher.

Zumachen: Zunächst einmal kümmern wir uns um die remote Referenzen: Das neue Repository einfach per push zu publizieren kann unangenehme Folgen haben, aber auch ein pull könnte uns Probleme bereiten. Da ich nicht dumm genug bin, das auszuprobieren, glaube ich den Warnungen und entferne erstmal die Remote-Verbindungen:

# ~/p1/ > git remote show

origin

# ~/p1/ > git remote show origin

* remote origin

   URL: /home/me/projekte

   Remote branch merged with 'git pull' while on branch master

     master

   Tracked remote branch

     master

# ~/p1/ > git remote rm origin

So, jetzt kann es nicht mehr so einfach passieren, daß eine versehentlich verschüttele Kaffeetasse ein git push auslöst und unser Original verschandelt, von dem wir geklont haben. Ok, ganz ehrlich, viel kann da nicht passieren, aber sicher ist sicher. Wir haben jetzt ein schickes Repository, was wir unsererseits gleich mal klonen und verteilen können.

Nachdem wir wissen, wie's geht, wiederholt der Pförtner die Schritte für die anderen vier Projekte, die Vorstellung ist vorbei, das Original-Monster-Repositories unterschreibt noch schnell, in Zukunft keine Änderungen mehr zuzulassen und wird in ein Taxi am Bühneneingang geschoben, von wo es nie mehr zurückkehrt (es lebt jetzt mit einer Frau und drei Kindern auf Hawaii und arbeitet da in einer Telefonmarketing-Firma, ist aber ansonsten recht glücklich), und die jetzt getrennten siamesischen Fünflinge gehen gemeinsam auf Welttournee (sie sind sehr erfolgreich, allen zu erzählen, wie wunderbar es sicht getrennt lebt, und treten gemeinsam bei praktisch jeder Fernsehtalkshow auf, ohne jemals irgendetwas von Bedeutung getan zu haben). Git ist schon wieder auf dem Golfplatz und erklärt jedem, der es hören oder nicht hören will, wie unnütz und rundheraus dumm und häßlich Subversion und der Rest der häßlichen Verwandschaft ist, und wie glücklich alle sein können, daß es ihn gibt, aber da hört schon keiner mehr hin, weil alle an der Bar sitzen und sich über nervige Typen in Armani-Anzügen auslassen.

Na, das war ja mal Drama. Also, jetzt mal ganz ehrlich: Kann das Dein SCM?

Git und Windows: Elf Schritte (und in paar Fotos)

Die netten Leute von github haben sich mal aufgerafft und eine Kurzanleitung zusammengebaut, mit der jeder, der in der Lage ist, einen Brief zuzukleben ohne sich Gummierung in die Augenbrauen zu schmieren, auch die Grundfunktionen von git unter Windows in Betrieb nehmen kann.

Das Schöne daran: Im Gegensatz zu den üblichen Methoden verzichtet diese Anleitung auf Cygwin (was vielen Windows-Nutzern den Zugang erleichtern sollte). Allerdings will ich nicht verschweigen, daß man mit einem unixoiden Unterbau noch mehr Freude an git haben kann...

Traumreisen ohne MBP?

Ja, da kann man schon ins Träumen kommen: Apples neues 17" MacBook Pro (MBP - wer erfindet eigentlich immer diese Abkürzungen?) erweckt erstmal den Eindruck, daß diesmal wirklich alles richtig gemacht wurde. Ein großer Bildschirm, diesmal auch entspiegelt erhältlich, viel RAM, aktuelle Prozessoren, aktuelle GPUs, ein schickes und schlankes Gehäuse, und obendrauf sagenhafte 8 (acht!) Stunden Laufzeit. Na, ist das ein Grund, sich dieses Jahr kein neues Auto sondern einen Mac zu kaufen?

(Oh, sorry, ähnliche Kommentare haben im Anschluß an den entsprechenden Artikel auf Golem natürlich wieder den üblichen Flamewar gestartet. Da halte ich mich lieber raus.)

Offenbar nutzt Apple die Erfahrungen aus dem iPod-Bereich jetzt auch für die Notebooks. Aber, typisch für mein ambivalentes Verhältnis zu meinem Lieblings-Hardwarehersteller, irgendwie habe ich das Gefühl, zum Schluß doch noch eine Kröte schlucken zu müssen: Der sagenhafte Monster-Akku ist fest eingebaut. Was sie sich wohl dabei gedacht haben? Ist der Akku leer, hilft kein Ersatzakku, egal, wie weit die nächste Steckdose entfernt ist. Und: Ist der Akku verschlissen, muß ein neuer bei Apple eingebaut werden.

Über die Kosten (laut dem heise-Artikel "Macworld: 17-Zoll-Macbook mit mattem Display"179 Euro) will ich hier mal nicht meckern, das Gerät wendet sich an betuchte Anwender, und für 8 Stunden Laufzeit und immerhin 1000 Ladezyklen ist das nicht zu teuer. Im Grunde sollten die Ich-laß-das-Preisschild-dran-Typen jetzt unglücklich werden.

Nein, das Problem ist: Wenn man so eine Maschine besitzt, will man damit arbeiten. (Ich würde es wollen.) Und ein toter Akku sorgt in diesem Falle dafür, daß die Maschine (und alle Daten darauf) aus dem Büro muß, möglicherweise für Tage (und dann auch noch fremden Leuten zugänglich sind). Das kann schon unangenehm werden.

Wie wär's mit einem Kombi-Angebot? Zwei Wochen Urlaub auf Hawaii, in der Zeit macht Ihr MBP eine Wellness-Kur in Kalifornien. Flug und Hotel nicht inklusive.

Verteiltes SCM

Eigentlich suchte ich ja nach einem Hoster für Ruby on Rails-Projekte. Aber wie immer im Leben passiert dann etwas Anderes. In diesem Falle stolperte ich über ein Video: Tech Talk: Linus Torwalds on git. Das ist wirklich bemerkenswert unterhaltsam, auch wenn ich zugeben muß, daß in etwas mehr als einer Stunde nur zwei Aussagen von Substanz getätigt werden:

• SCM muß verteilt sein
• Performance ist wichtig

Inhaltlich ist über den Rest des Videos nicht viel zu sagen: Ein netter, junger, begrenzt freundlicher Mann produziert sich mit sichtbarer Erfahrung auf der Bühne, ein Haufen Techies sitzen drum rum. Man merkt nach einiger Zeit, daß man es mit Google-Leuten zu tun hat: Keine anhimmelnden Gesichter, nur blanke Skepsis.

Erinnerung: Wenn ein Techie einem anderen Techie begegnet, von dem auch die Großmutter seiner Frau schon mal gehört hat, der also bereits mehrfach mal in den üblichen Massenmedien erwähnt wurde, legt er seine Haltung gegenüber dem Fremd-Techie im Vorfeld fest, und zwar entweder auf "Elvis!!!(kreisch)" oder auf "Du hast keine Ahnung, wie wir das hier im Maschinenraum machen", und behält diese Einstellung eisern zumindest bis zum Ende der Konfrontation bei.

Zurück zum Thema.

Die Argumente, warum ein SCM unbedingt verteilt sein muß, sind leider etwas verwaschen (obwohl ich die gleiche Meinung habe, mit der Abweichng, daß ich schon gerne ein Master-Repository habe, wenn auch nur, um einen zentralen Referenzpunkt zu haben) und mengen sich mit der Argumentation, warum Performance wichtig ist: Weil dann eine andere Arbeitsweise möglich wird. Aber natürlich ist mir unten in meinem Maschinenraum auch noch kein besseres rationales Argument eingefallen.