Re: [Frunge] Git-Repository

[Dennis Heidsiek]

Hallo allerseits,


Martin Roppelt schrieb am 18.05.2009 15:52 Uhr:
> Immer mal langsam mit den jungen Pferden!
>
> Ich finde es schön, dass du gleich mit Feuereifer dabei bist!

Dieses Kompliment kann ich nur zurückgeben! :-). Du legst schließlich 
ein beachtliches Tempo vor; so haben wir inzwischen gleich drei 
Repositories: Git, SVN und CVS.

> Wir haben wie gesagt Zeit, und die Einrichtung des git-Repos will 
> wohlüberlegt sein.
>
> Nicht, dass wir überstürzt handeln, und es später bereuen!

Ja, da gebe ich Dir Recht: Es macht Sinn, da gleich von Anfang an 
Struktur hineinzubringen. Also los geht’s:

> Ich möchte festhalten, dass es keinen Sinn macht, die fertigen otfs in 
> das Repo einzuchecken. Das ist erstens für Quellcode gedacht, und 
> zweitens muss es bei jedem git-commit durchgeführt werden (was auch 
> bei einem hook über fontforge (geht der eigentlich auch unter 
> Windows?) – zumindest später Zeit braucht).

Na ja, kompilierte »Nightly Builds« (oder wie auch immer man das nennen 
will) haben durchaus Vorteile, da sich ein neuer Interessierter Nutzer 
nicht erst groß einarbeiten muss (Repository auschecken / Fontforge oder 
makefile starten), sondern direkt das fertige Endergebnis herunterladen 
und ausprobieren kann. Ich gebe Dir aber vollkommen damit recht, dass 
dies die Dinge technisch verkompliziert und zudem auch keine »saubere« 
Lösung wäre, weshalb ich Dir in diesem Punkt hiermit (trotz leichter 
Bauchschmerzen) zustimme. Fertige kompilierte Versionen der Schriften 
(und der Dokumentation) sollten also nur im »Dokumente« Bereich der 
Savanne im Rahmen eines »richtigen« Releases (Frunge 0.1?) auftauchen. 
Wobei ich persönlich überhaupt nichts dagegen hätte wenn wir uns darauf 
einigen würden, dass bei großen (oder schönen) Änderungen eben schnell 
eine otf-Datei über die Mailingliste huschen würde.

Unter Windows einen Hook einzurichten, der mit Fontforge die 
.sfd-Quellen kompiliert, wäre sicherlich irgendwie möglich, aber frage 
mich nicht wie bzw. wie aufwändig das wäre ;-). Außerdem müsste ein 
derartiger Hook sinnvollerweise sowieso serverseitig ablaufen, so wie 
bei Neo.

> Das Lizenzierungsmodell muss eingehalten werden:
>
> Eine README, die besagt, dass alle Dateien unter Copyright, GPL FE und 
> OFL stehen. Diese als COPYING im Wurzelverzeichnis und als README in 
> jedem Glyphenverzeichnis.

Grundsätzlich hast Du da meine volle Zustimmung, aber ich hätte eine 
technische Frage: Warum können die Lizenzhinweise nicht überall 
einheitlich »COPYING« (»LICENCE« ist unüblich?) heißen? In einer 
Readme-Datei erwarte ich eher eine grobe Übersicht, was den überhaupt in 
diesem Verzeichnis zu finden ist.

> Wir sollten uns auch auf eine Richtlinie für Commit-Messages einigen:
>
> <s>NEW (oder </s>ADD<s>?)</s> voranstellen für neu eingebrachte 
> Änderungen, Erweiterungen FIX für Fehlerbehebungen oder Änderungen

Ich würde eher zu ADD tendieren, aber so eine »Präkatigorisierung« der 
Commit-Messages finde ich auch sehr sinnvoll :-). Zudem sei auch hier 
nochmal explizit wiederholt, dass die Lognachrichten konsequenterweise 
auf Englisch erfolgen sollen.

> Die erste Zeile sollte eine prägnante Zusammenfassung geben, gefolgt 
> von einer Leerzeile. Man muss bedenken, dass diese erste Zeile häufig 
> als einzige angezeigt wird.

Okay, die Forderung nach der Leerzeile kannte ich noch nicht, werde ich 
aber versuchen zu beherzigen.

> Dann möchte ich noch sagen, dass ich, was git betrifft, noch grün 
> hinter den Ohren bin. Das heißt, ich muss üben!

Das muss ich noch viel mehr, so grün wie ich kannst Du gar nicht sein 
;-). – ich glaube, Arno hat von uns bisher die meiste »Real 
World«-Erfahrung mit Git sammeln können.

Können wir aber nochmal eben über das Thema »Branches« sprechen? Ich in 
meiner Git-Naivität hätte jetzt erwartet, dass es in unserem 
Git-Repository pro Schrift einfach ein .sfddir-Verzeichnis geben würde. 
Dem Log zufolge hast Du stattdessen aber neben dem »master« noch einen 
»textura« Branch erstellt – kannst Du mir das bitte nochmal kurz erläutern?

Und wo wir gerade beim Thema »Repository-Aufteilung« bin: Derzeitig 
haben wir drei davon:
• Git: Für die Sourcen der Schriften,
• SVN: Für die Sourcen der Dokumentation,
• CVS: Für die Dateien unserer Hompage¹.

Für Unstrittig halte ich das CVS-Repo (da dies anscheinend so von der 
Savanne vorgegeben ist, um die Hompage zu verwalten) und das Git-Repo 
(da dies die von Euch präferierte Versionsverwaltungsſoftware ist). Aber 
brauchen wir wirklich noch ein SVN, nur um die Schriften und die 
Dokumentation in verschiedenen Repos zu halten?

Schließlich liegt doch auch die Dokumentation in einem Quelltext-Format 
(.tex) und nicht im kompilierten Format (.pdf) für den Endnutzer vor 
(diese gehört vielmehr zu den otf-Dateien bei den Releases unter 
Dokumente). Deshalb würde ich grundsätzlich dafür plädieren, Git- und 
SVN Repository zu vereinigen, etwa
Git/README
Git/COPYING
GIT/GPL …
Git/Font/
Git/Font/Textura
Git/Font/Fraktur …
Git/doc/
Git/doc/en/manual.tex …

Martin, Arno, sagst mir einfach, wenn ich hier gerade Stuss verzapfe ;-).

Noch eine Kleinigkeit: Was genau spricht dagegen, Textdateien mit der 
Endung .txt (oder auch .utf8?) zu versehen, um den Dateityp zu 
verdeutlichen – oder denke ich da gerade zu Windows-artig?

> Und: Wichtige Änderungen (und Änderungen, die nicht unumstritten sein 
> können) vorher absprechen!

Wie ich schon in der anderern E-Mail schrieb: Einverstanden. Wobei man 
manchmal aber leider erst im nachhinein merkt, dass eine Änderung 
strittig war ;-).

> > ¹ Ich bin ja eigentlich eher SVN-Fan, aber inzwischen scheint 
> > Tortoise-Git einigermaßen brauchbar geworden zu sein  :-) .
>
> Hast du dir schon mal Gedanken darüber gemacht, die Variante über 
> glaube ich Cygwin zu versuchen? ;) Die Kommandozeilen-Version?

Ich benutze derzeitig die native Windows-Neuimplementierung msysgit 
<http://code.google.com/p/msysgit/>² als »Unterbau« (hat die 
Cygwin-Lösung abgelöst) und TortoiseGit³ als »Klickibunti«-Aufsatz für 
ein bequemes Arbeiten. Der Kommandozeile bin ich aber nie abgeneigt, und 
tatsächlich bringt msysgit auch das Kommando »Git Bash here« mit sich – 
die läuft zwar über MingGW und nicht Cygwin, aber die Befehle sollten 
dieselben sein :-).

> Wenn du mal  später auf GNU/Linux umsteigen solltest, ist das ganz 
> praktisch.

Gutes Argument :-).

> Für mich persönlich ist das Arbeiten mit grafischen Programmen bei 
> einer Versionsverwaltung immer ein bisschen ein Krampf und ich 
> empfinde die Shell-Arbeitsweise als angenehmer.

Ich habe wirklich nichts gegen die Kommandozeile und nutze sie auch, 
aber gerade bei einer Versionsverwaltung finde ich es sehr praktisch, 
wenn mir lokal geänderte Dateien, die ich noch nicht commitet habe, mit 
einem roten Icon angezeigt werden. Jeder muss die Arbeitsweise finden, 
die er jeweils für angemessen hält :-).

Wobei ich unter Windows auch die PowerShell⁴ recht brauchbar finde, die 
standardmäßig mitgelieferte Kommandozeilenversion ist zwar für die 
grundlegenden Dinge ausrechend, sollte aber besser den Vergleich mit den 
mächtigeren *ux-Äquivalenten scheuen.

> Auch wenn das bedeutet, dass man sich erst einmal darin einarbeiten 
> muss. Aber das muss man ja bei git sowieso.

Das kann ich definitiv unterschreiben, die Neo-SVN-Einrichtung (mit Name 
und Passwort) ist unter Windows viel einfacher. Bei lokaler Nutzung 
gefällt mir Git durchaus, aber sobald man sich mit einem fremden Repo 
verbinden will nehme ich Git unter Windows bisher einfach nur als 
Ansammlung von Verschlechterungen wahr. Aber vielleicht kommt meine 
große Git-Erleuchung ja noch … vielleicht sogar schon an diesem 
Wochenende ;-).


Viele Grüße,
Dennis-ſ


¹ http://www.nongnu.org/frunge/
² http://code.google.com/p/msysgit/
³ http://code.google.com/p/tortoisegit/
⁴ http://de.wikipedia.org/wiki/Windows_PowerShell