frunge-internal
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Frunge] Git-Struktur (was: Git-Neuaufbau)


From: Martin Roppelt
Subject: [Frunge] Git-Struktur (was: Git-Neuaufbau)
Date: Wed, 03 Jun 2009 07:46:14 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090319)

Dennis Heidsiek ſchrieb:
Martin Roppelt schrieb am 02.06.2009 05:21 Uhr:
Hm, hatte keine Zeit mich um Frunge zu kümmern :(

Bei unserem Projekt gibt es doch auch keinen Zeitdruck :-).

Stimmt. Deswegen ſollten wir ja auch nicht wild drauf los committen :(

dafür habe ich ein sehr vielversprechendes (und sogar deutschsprachiges!) Blog über Git entdeckt:

git ready – Lerne Git Commit für Commit von Nick Quaranto, Übersetzung von Nico Gulden http://de.gitready.com/

Hey! Sieht gut aus!

… oder wenn – wie gerade geschehen – die Savanne austrocknet,

Ich liebe deine Wortſpiele :)

das komplette (d.h. inklusiver aller alten Versionen und Logeinträge)
Git auf dem Server wiederherstellen. Bei einem SVN/CVS hätten wir nur die letzte aktuelle Version gehabt, aber bei Git ist jedes Repo komplett eigenständig :-). Ich glaube, ich habe soeben den ersten überzeugenden Grund für mich gefunden, Git zu verwenden :-).

Siehſt du? :)

Und auch das Diagramm in dem Artikel finde ich sehr gelungen, damit kann ich mir endlich den ganzen Haufen der neuen Git-Kommandos effizient einprägen :-).

Ich habe jetzt nicht mehr in Erinnerung, wie die Ordner benannt waren, aber in etwa so? /OFL, /GPL, /FDL, /CC-BY-SA, /COPYING, /src, /doc, /src/Hybrida.sfdir, /src/Hybrida.sfdir/README(so!)

Fast … anstatt von /src/ und /doc/ hatte ich /Font/ und /Documentation/ hochgeladen (›eingepusht‹?). Aber an dieser Frage hängt nicht mein Seelenheil … /src/ und /doc/ sind weit verbreiteter Quasi-Standard, andererseits sieht /src/Hybrida/ von der Ordnerschreibweise her uneinheitlicher aus als /Font/Hybrida/.

Habe nochmal nachgedacht:
/font/
/doc/
(/doc/deutſch/)
/doc/engliſh/Manual.tex
COPYING
(diverſe Lizenzdateien) [vielleicht in einem extra Ordner /licenſe(s)/?]
/font/Mixtura/
/font/Mixtura/{font.props,*.glyph,README}

Ich finde, daſs wir nicht in jedem Verzeichnis eine komplette COPYING
brauchen. Nur im Wurzelverzeichnis.

Dort brauchen wir wiederum keine README (hm, oder doch?), allerdings kann man es ſich auch unnötig kompliziert damit machen.

Die Copyright- und Lizenzinformationen der Doku kann man ja in die Dateien direkt ſchreiben.

andererseits sieht /src/Hybrida/ von der Ordnerschreibweise her
uneinheitlicher aus als /Font/Hybrida/.

Bitte ſei vorſichtig mit der Länge der Verzeichnispfade! Und ſparſam mit
der Großſchreibung!

Ach ja: Mit einem abschließenden Schrägstrich kennzeichne ich Ordner,
um sie so eindeutig von Dateien unterscheiden zu können (also /COPYING, aber /Font/).

Allerdings wird dann dieser Text kursiv dargestellt, was nicht wirklich schön ist … deshalb werde ich zukünftig \ oder | als abschließenden »Ordnerindikator« verwenden.

Wieſo, ſieht doch ſchön aus!

Wobei es auch nicht schwer zu sein scheint, das Git wieder auf den »Vor-Crash-Stand« zu bringen:

Git: […] c) You can push a local version if you have one (git push --all; git push --tags) You can import the repository directly, without our help.

https://savannah.gnu.org/forum/forum.php?forum_id=5828

Ich werde das heute Abend erledigen, wenn jetzt kein Widerspruch kommt – was mich zu der folgenden Ausſage von Martin bringt:

Fürs erste wäre ich dafür, dass wir unser Repositorium von der Grundstruktur nicht im git aufbauen (vllt. in der Downloadarea?).

Ja, oder vielleicht hier auf der Mailingliſte… oder ſonſtwo, nur nicht
im repo :) Ich will, daſs die Grundſtruktur ſteht, und daſs ich mit ihr
auch leben kann :)

Hä? Was meinst Du? Du willst unserer Repository jetzt doch nicht als Git realisieren? Sondern auf alle schönen Git/VCS/DVCS-Versionierungs/Branch-Features verzichten und stattdessen die Dateien »nackt« in den Download-Bereich stellen? Da bin ich absolut dagegen, wir sollten das Git wie bisher nutzen. Und die Downloadarea sollte genau dafür genutzt werden, wofür sie da ist: Für Downloads bzw. Fertige Releases (etwa Frunge-0.5.tar, Frunge 1.0.tar, …), die sich der Normalnutzer herunterladen und nutzen kann. Das Repo hingegen ist für uns Entwickler da.

Und dass wir alle unsere Commits mittels git-format-patch/git-send-mail auf der Mailingliste vordiskutieren sollten.

Iſt zurückgenommen.

Also nee … Das finde ich nun wirklich unnötig kompliziert. Wofür haben wir ein Git-Repo, wenn wir es nicht nutzen, sondern uns stattdessen hier auf der Mailingliste mit Patch-Dateien bombardieren? Patch-Dateien sind doch eher für Leute ohne effizienten Internet-Zugang oder vor allen Dingen für Leute ohne Schreibberechtigung interessant (so kann ein »Externer« einen Patch erstellen und sie dann einem Entwickler per E-Mail zuschicken). Aber bei uns trifft das nicht zu und führt nur zu vollkommen unnötiger Verwirrung. Das Repo ist ja nicht für den Endnutzer gedacht, sondern für uns Entwickler. Wenn einer etwas einstellt, haben die anderen beim nächsten Fetch die bequeme Möglichkeit, sich alle »angelaufenen« Änderungen im Log (bzw. die Diffs) anzusehen, zu redigieren und ev. Korrekturen einzustellen. Genau dafür ist ein Versionskontrollsystem da, dass sollte nicht über die Mailingliste laufen.

Bin dafür mich zum (alleinigen) Maintainer zu machen ;) <-- nicht überſehen!

Will halt nur nicht, daſs irgendſoetwas unausgegorenes da reinſchneit ;)

Gruß,
Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]