[linux-l] Nutzt jemand Git?

[Steffen Dettmer]

* Volker Grabsch wrote on Sun, May 17, 2009 at 09:17 +0200:
> Eng damit verwoben ist die Frage nach guten Clients. Ich persönlich
> finde die Kommandozeilen-Oberfläche von Darcs sehr genial und
> leicht erlernbar. Die von Mercurial ist nicht ganz so toll, aber
> immer noch vergleichbar mit SVN, d.h. relativ wenige Kommandos
> mit klarer Semantik. Die Kommandozeile von Git hingegen finde
> ich grauenvoll. 

Ach echt? Warum denn das? Mir gefällt sie. Kann man sich ja sogar
noch umdefinieren. HG hab ich nie weiter benutzt und selbst das
ist lange her, aber war das nicht so grundsätzlich eher ziemlich
ähnlich? Wobei, soweit mein Eindruck, Git deutlich mehr kann und
damit natürlich deutlich mehr Kommandos kennt (die man vielleicht
nicht unbedingt benutzen muss :)).

> Dabei ist Git von den Konzepten her gar nicht so kompliziert.
> Meiner Meinung nach ist es deren umständliche Umsetzung an der
> Kommandozeile, die abschreckend wirkt.

Was ist da umständlich (im Vergleich zu HG und CVS oder so)?

> Ich hätte einige SVN-Projekte längst gern nach Mercurial
> portiert (oder zur Not nach Git), grundsätzliches Interesse
> war vorhanden. Aber es gab keine guten Windows-Clients - nichts,
> was irgendwie an TortoiseSVN heran kommt. Und dabei ist TortoiseSVN
> auch noch stark verbesserungsfähig.

Ich finde TortoiseSVN und TortoiseCVS eher doof. Kommandozeile
find ich besser. Geschmackssache, denke ich. TortoiseCVS
verzweifelt wohl auch ganz schön, wenn man mehrere Sandboxes
ineinander auscheckt. Die Shellintegration mit diesen komischen
Icons kostet viel Performance (kann man vermutlich abschalten,
keine Ahnung).

> Etwas mit TortoiseSVN vergleichbares für Git gibt es nicht, oder?

Git bringt doch schon ne GUI mit, wozu da noch so'n
http://code.google.com/p/tortoisegit/
? Git-Cheetah ist wohl ähnlich. Kann ich aber nichts zu sagen,
weil ich es ja alles nicht nutze, überhaupt mit Win nicht so gut
arbeiten kann. Nutze TortoiseSVN und TortoiseCVS nur dazu, um
screenshots zu machen (komischerweise brauchen manche die Leute,
die das nutzen, screenshots - bei Kommandozeile ja nicht).

> Auch unter Linux sieht es mau aus - nicht jeder Linux-User ist
> ein Fan der Kommandozeile. Und selbst dort hat eingentlich nur
> Darcs ein gutes User-Interface. Einem DVCS-Neuling würde ich
> unter Linux daher immer Darcs empfehlen, auch wenn er für größere
> Projekt wohl auch Mercurial oder Git umsteigen muss.

git-GUI ist gar nicht brauchbar? Hab's mir nicht angeschaut. gitk
hingegen schon. Gefällt mir. Mir fallen natürlich trozdem Wünsche ein :)

> Jenseits von reinen VCS-GUIs und VCS-Kommandozeilen gibt es
> noch die Editoren und IDEs. CVS und SVN sind in die meisten
> IDEs viel besser integriert als die DVCS.

Die meisten Integrationen fand ich blöd. Führt wohl (aus
nicht-technischen Gründen) eher zu... sagen wir mal... komischer
Verwendung und eher schlechten Kommentaren. Eher weniger
selektive Checkins. Aber alles gerade, keine Statistik gemacht :)
Meist (immer?) scheitert es aber sowieso schon, wenn man in einer
CVS Sandbox anderen Sandboxes auscheckt. Hab noch keinen Clienten
gesehen, der da mit Tags richtig umgehen konnte. Mit SVN geht das
ja (soweit ich weiß) eh alles überhaupt nicht, damit hat man
natürlich in der IDE auch kein Problem damit :-)

Ich glaube, die meisten verwenden es einfach gemischt. Für die
alltäglichen Sachen IDE oder andere kleinere Helferlei (und wenn
es im vim ein :!cvs ... ist :-)), für manches (taggen und mergen
vielleicht) dann Kommandozeile. Ich halte das für einen guten,
prakmatischen Weg.

> Die Clients für die DVCS werden mit der Zeit besser. Aber es
> bedeutet halt, dass ich für _bisherige_ Projekte oft ein SVN-
> Repository anlegen musste, und wenn ein Projekt erstmal unter
> SVN läuft - naja, kennt ihr ja. Ein andere VCS lässt sich viel
> leichter bei einem _neuen_ Projekt einführen.

Wenn man bei einem neuem Projekt vom scratch anfängt, macht man
IMHO oft was falsch (in einer Firma mein ich). Irgendwo hat man
sicher schon irgendwas gemacht, worauf man aufsetzen möchte und
sollte (und wenn es ein logmodul ist). Daher kann ich mir das
überhaupt nicht vorstellen - bei uns sind viele Module in breiter
Wiederverwendung.
Daher könnte ich mir sogar vorstellen, dass man kleiner, alte
Basismodule zuerst migrieren wollen würde, oder das man die
Git-Ergebnisse vorerst nochmal nach CVS schiebt (und da seine
Releases baut). Wenn beides parallel läuft und jeweils 100%
bitweise gleiche Ergebnisse entstehen, kann man halt Git oder SVN
zum bauen nehmen und dann hat man es geschafft :-)

> > Erstens kann man ein DVCS immer auch komplett zentral verwenden, wenn
> > man es wirklich wiklich will. (Naja, zumindest Git... Die Anderen kenne
> > ich nicht, um es wirklich beurteilen zu koennen.)
> 
> Ja, auch Mercurial, Darcs & Co. kannst du wie SVN verwenden.
> Aber dann macht ein Entwickler mehrere Commits und vergisst
> den Push - eine gewisse Umgewöhnung von SVN ist nunmal da,
> und das provoziert Fehler.

Kann man denn git nicht so scripten, dass immer gepusht wird?
Es passiert ja selbst bei CVS und SVN auch schon manchmal, dass
was nicht eingecheckt wird. Wobei bei SVN und neuen Files
vielleicht sogar häufiger, weil die Dateien per default ja nicht
als unknown angezeigt werden.

Ich finde auch, dass der `Zusammenschluss von Repo und Sandbox'
bei den DVCS nicht unbedingt nur ein Vorteil ist. 

Bei Git ist das IMHO aber eine Ansichtssache. Man kann sich das
auch als zentrales remote-repo mit `dreistufigem Commit'
vorstellen (add - commit - push). Finde das sogar irgendwie
logisch, so gefühlsmässig, kann es aber nicht erklären :)
Geht so in die Richtung, dass man seine Änderungen sorgfältig
macht. Im Gegensatz zu SVN stellt man sein changeset manuell
zusammen, vergibt Kommentare und fasst dann mehrere Changesets
zusammen, die man dann `eincheckt' (also in ein bare repo pusht).

Macht das Sinn?

> Es gibt zwar SVK, aber da finde ich es doch einfacher, das SVN-
> Arbeitsverzeichnis lokal nochmal in ein Mercurial-Repository zu
> packen. :-)

Hatte auch schon überlegt, einfach ne CVS Sandbox zum git repo zu
erklären. Scheitert dann an den $Header$ keyword substitutionen,
aber für `mal gucken, was passiert, wenn ich hier folgendes...'
müßte es eigentlich reichen. Wär auch schon mal was.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.