[Top][All Lists]
[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
- [Frunge] Re: Git-Neuaufbau, (continued)
- [Frunge] Re: Git-Neuaufbau, Dennis Heidsiek, 2009/06/02
- Re: [Frunge] Re: Git-Neuaufbau, Martin Roppelt, 2009/06/02
- Re: [Frunge] Re: Git-Neuaufbau, Dennis Heidsiek, 2009/06/02
- Re: [Frunge] Re: Git-Neuaufbau, Arno Trautmann, 2009/06/03
- Re: [Frunge] Re: Git-Neuaufbau, Dennis Heidsiek, 2009/06/04
- Re: [Frunge] Re: Git-Neuaufbau, Martin Roppelt, 2009/06/04
- Re: [Frunge] Re: Git-Neuaufbau, Martin Roppelt, 2009/06/04
- Re: [Frunge] Re: Git-Neuaufbau, Arno Trautmann, 2009/06/04
- Re: [Frunge] Re: Git-Neuaufbau, Martin Roppelt, 2009/06/04
- Re: [Frunge] Re: Git-Neuaufbau, Dennis Heidsiek, 2009/06/05
- [Frunge] Git-Struktur (was: Git-Neuaufbau),
Martin Roppelt <=
- Re: [Frunge] Git-Struktur, Martin Roppelt, 2009/06/04
- Re: [Frunge] Git-Struktur, Dennis Heidsiek, 2009/06/05
- Copyleft-Logo (was: Re: [Frunge] Git-Struktur), Dennis Heidsiek, 2009/06/05
- [Frunge] Re: Copyleft-Logo, Martin Roppelt, 2009/06/05
- Re: [Frunge] Re: Copyleft-Logo, Dennis Heidsiek, 2009/06/06
Vorgaben für die Schriftnamen (was: Re: [F runge] Ist das Git down?), Dennis Heidsiek, 2009/06/02
[Frunge] Re: Vorgaben für die Schriftnamen, Martin Roppelt, 2009/06/03