[linux-l] Nutzt jemand Git?

[olafBuddenhagen at gmx.net]

Hallo,

On Mon, May 04, 2009 at 11:58:31PM +0200, Steffen Dettmer wrote:

> nutzt hier eigentlich jemand Git (DVCS)?

Freilich.

> Hat jemand praktische Erfahrungen in grösseren Projekten? Im Kernel
> läufts ja wohl gut, sonst hätten sie es anders gemacht :)

Ich habe bisher nicht aktiv an einem solchen Projekt gearbeitet... Aber
passiv konnte ich den Umstieg bei X.org recht gut verfolgen.

> Überhaupt, wenn man Git (oder hg) haben kann, warum würde man SVN
> nehmen?  Ich habe danach gegoogelt, aber meist pro-Git-Artikel
> gefunden, die wohl weniger objektiv sind. Anscheinend verwenden ja
> sehr viele SVN. Bei uns in der Firma will man uns am liebsten nach SVN
> migrieren. mmm... Heute noch zu SVN? Für mich wirkt SVN eher wie ein
> CVS mit ein paar Bugfixes (und paar weniger Features, die die meisten
> aber nicht brauchen).

Sehe ich auch so. Ich kann einfach nicht verstehen, warum jemand noch
SVN nimmt, wenn es so viel bessere Sachen gibt.

> Praktisch interessiert mich aber, ob Git in der Praxis auch für
> `nicht-Freaks' nutzbar ist (z.B. für outsourced development).

Was sind denn "nicht-Freaks"? Jemand der Programmieren kann, sollte
keine Probleme haben, Git zu lernen. Wenn man das seinen Leuten nicht
zutraut, sollte man sich besser nach neuem Personal umschauen...

Wenn man hingegen die Grafik-Designer oder so dazu bringen will,
Versionskontrolle zu verwenden, koennte man eventuell ueberlegen, was
Anderes zu nehmen. Habe aber keine Erfahrung mit Mercurial oder Bazaar,
um bestaetigen zu koennen, ob die wirklich einfacher zu lernen sind...
Ich kann mir ehrlich gesagt nicht vorstellen, dass der Unterschied so
grosz ist, wie viele Leute behaupten.

Das Problem mit Git ist, dass es ein paar Grundkonzepte hat, die man
erstmal verstehen muss, um es vernuenftig benutzen zu koennen... Diese
Konzepte sind eigentlich ganz simpel -- aber man muss sich eben die
Muehe machen, sie zu lernen.

Dazu kommt, dass Git anders ist. Mercurial und Bazaar versuchen
weitestgehend SVN nachzubilden, was wiederum versucht weitestgehend CVS
nachzubilden. Git versucht das nicht. Git ist Git. Ein paar Kommandos
sind aehnlich, und funktionieren auch tatsaechlich mehr oder weniger
genauso. Ein paar Kommandos scheinen aehnlich, machen aber etwas
anderes. Einige sind voellig anders.

Die Folge von Beidem ist, dass man sich mit Git tatsaechlich ein wenig
auseinandersetzen muss (d.h. Dokumentation lesen), bevor man anfaengt es
zu benutzen; an sonsten *muss* es schief gehen. Die meisten Leute wollen
sich die Muehe aber nicht machen, sondern unbedingt gleich loslegen...

Diese Leute sind erfahrungsgemaesz die ersten Monate arg am jammern. Bis
sie es dann schlieszlich halbherzig benutzen koennen. Irgendwann lernt
man es halt auch auf die harte Weise...

> Allerdings braucht man auch Konventionen, beispielsweise wie ein (oder
> mehrere) Austausch-Repos zu verwenden sind. Im Git Handbuch ist ein
> Diagramm mit zwei Partnern. Dort hat jeder ein public repo. Kann man
> da nicht auch einfach ein gemeinsames public repo nehmen?

Freilich kann man. Die Git-Entwickler versuchen diese Moeglichkeit immer
etwas unter den Tisch zu kehren; aber einer der groszen Vorteile von Git
ist gerade die enorme Flexibilitaet in der Arbeitsweise.

X.org benutzt ein etwas gemischtes Modell: Es gibt das zentrale
Repository, aus dem alle Releases gemacht werden. Einzelne Entwickler
veroeffentlichen waehrend der Arbeit an groeszeren Neuerungen aber
teilweise auch eigene Repositories.

> BTW, autoconf kann zwar prima in subdirs, aber mindestenes ältere
> Versionen mögen keine symlinks. sandbox (repo) in ~/ und build in /tmp
> geht also leider in der Praxis dann auch nicht... Oder???

Wozu Symlinks? "mkdir /tmp/foo && cd /tmp/foo && ~/foo/configure &&
make"

Oder meinst Du was anderes?

> Bei Git braucht man das nicht - lieber möchte man nur eine Sandbox und
> die dann umschalten (also checkout <otherbranch>).
> 
> Funktioniert das in der Praxis? Wie stehen die mtimes? Klappt alles
> mit make? Wenn sich ein configure.in (.ac) ändert, dann bau ich doch
> jedes Mal alles neu?! Da sich wegen der Versionsnummer das
> configure.in und damit config.h, wird doch immer /alles/ neugebaut?!

Ich bin ziemlich sicher, dass sich beim Wechseln des Branches nur bei
den Dateien die mtime aendert, die tatsaechlich unterschiedlich sind...

Aber das hilft Dir natuerlich nicht, wenn sich eine Datei aendert, die
ein Neubauen von allem erzwingt. Da kann Git auch nix machen. Keine
Ahnung was Du Dir da vorstellst.

> Tja, und noch ein Detail. Ich CVS-Files haben wir immer schön "$Name:
> $". Das hat einen wichtigen Grund. Wenn nämlich jemand ein CVS Export
> File ändert und uns zurückschickt, weiß er nicht, wo er das mal
> herhatte. Damit kann ich das nichtmal diff'en oder einchecken (weiß ja
> nicht, in welchen Branch und von wo aus). Dank $Name: $ (und $Header$)
> ist das einfach. Entweder hab ich ne Revision oder ein Tag. Das check
> ich aus, schreib die Files drüber, `cvs diff' geht. Dann `cvs up' auf
> mein Ziel und dann kann ich einchecken. Wie macht man sowas günstig
> bei Git/HG?

Es gibt keine hartverdrahteten Features fuer sowas in Git; aber es gibt
Beispiele fuer entsprechende Hook-Skripte.

> Da gibts ja rein logisch keine globale ID für Versions-Stände (wohl
> aber für Änderungen, aber das hilft ja nicht).

Falsch. Git kennt in Wirklichkeit *nur* Staende, und deren Abstammung.
Die Terminologie ist da nur nicht ganz eindeutig: Ein "commit"
bezeichnet einen bestimmten Stand; und die zugehoerige sha1 ist global
eindeutig. Aenderungen ergeben sich ausschlieszlich durch Vergleichen
mit den vorhergehenden Staenden.

Das ist eins der Oben erwaehnten Grundkonzepte, die man verstehen muss,
um Git richtig benutzen zu koennen...

> Selbst bei einem Tag muss man ja dazu schreiben, wo es gilt (oder?).

Richtig, Tags sind im Prinzip nur lokale Namen fuer bestimmte Commits.
Wenn man eine global eindeutige Kennung braucht, muss man die sha1
direkt angeben, statt dem symbolischen Namen...

Wenn Du die sha1 in der Datei mitschickst, weiszt Du immer ganz genau wo
sie herkommt.

Ich ueberlege uebrigens, mich demnaechst mal wieder an Git-Vortraegen zu
versuchen...

-Olaf-