[linux-l] Nutzt jemand Git?

[Christoph Biedl]

Steffen Dettmer wrote...

> nutzt hier eigentlich jemand Git (DVCS)?

Ei freilich.

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

Der Kernel ist nicht wirklich ein großes Projekt, sondern vor allem
ein weit verteiltes. Dafür wurde git entwickelt, und das merkt man
dieser Suite auch weiterhin an (im Guten wie im Schlechten).

> Migriert heute eigentlich noch jemand zu SVN oder nimmt man
> gleich Git? Oder mercurial oder Bazar? Darcs eher gar nicht?

Die Wahl eines VCS ist sehr starke Sache der persönlichen Präferenzen
(man darf auch "Glauben sagen) und ist ein Thema für ausgiebige
Kriege, wenn man sich endlich auf den besten Editor (natürlich
mcedit) geeinigt hat. Ich persönlich zum Beispiel mißtraue großen
Programmen, die auf Skriptsprachen aufbauen (also bzr und hg).

> Ü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).

Ihr kommt von CVS? svn ist in einigen Dingen doch schon erheblich
fortschrittlicher, und wohl auch relativ schnell zu lernen, aber für
mich hat es zu sehr etwas von "altbacken". Es klingt albern, aber die
Geschwindigkeit von git im Status-Kommando macht einiges aus, auch
wenn es vielleicht nur 0,1 Sekunden statt 0,5 sind.

(...)

> 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?

git läßt hier viele Freiheiten und zwingt damit die Nutzer, sich selber
was auszudenken. Das übliche Verfahren ist verteilte Repositories und
integration manager, einen Ansatz mit zentralem Repository und commit
access für alle kann man immer noch fahren. Ich habe an der Stelle
mehr als einmal überlegt, in der Konstellation "kleine Firma, kleiner
Entwicklerkreis, der sich vertraut" mit einem svn repo zu arbeiten und
die Entwickler wählen zu lassen, welchen Client sie verwenden - da mir
aber der git-svn-Konnektor noch jedes Mal einen Haufen Trümmer erzeugt
hat, wenn ich damit rumprobiert habe, ist das allerdings nie geworden.

Die git-Verfechter vertreten recht lautstark die Meinung, daß das
von CVS und svn bekannte Konzept der Zentralisierung böse(tm) ist. Ich
vermag, gerade im obigen Szenario durchaus Vorteile darin zu sehen. Es
gibt jederzeit einen klar definierten Stand, und alle haben darauf
Zugriff. "integration manager" klingt nach einem Job mit viel Spaß
(Streß von allen Seiten), der ab einer gewissen Größe unvermeidbar
wird, aber bislang ging's bei mir auch ohne.

(...)

> Dann hab ich meist ne CVS Sandbox pro Branch. Klar, weil das mit
> CVS sonst nicht so gut geht (aber ich nutze auch gemixte
> Sandboxes). Bei SVN weiss ich das nicht, hatte da immer nur in
> jeweils einem Branch zu tun.  Bei Git braucht man das nicht -
> lieber möchte man nur eine Sandbox und die dann umschalten (also
> checkout <otherbranch>).

Mit Verlaub, das habe ich nicht verstanden, aber es klingt ziemlich
kra^Wanstrengend. Mit git hat sich auch mein Stil massiv verändert,
da mache ich branches häufiger als in svn commits. Und es lohnt sich.

> 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?! Das ist beim multi-sandbox-Ansatz nicht der Fall
> (jeder branch sein configure und sein config.h - das ist dann
> also fest).

git aktualisiert im Zweifelsfall die mtime, denn das ist ja gerade
eine Anwendung: Springt man in einen anderen branch, soll bitte eine
Neuübersetzung erzwungen werden.

(...)

> Tja, und noch ein Detail. Ich CVS-Files haben wir immer schön
> "$Name: $".

Das fehlt aus einem guten Grund. Ich müßte es raussuchen, in meiner
Erinnerung war es "Bläht die commits auf". Mit hooks könnte man sich
das nachbauen, aber ich habe keine Erfahrung damit.

> Das hat einen wichtigen Grund. (...)

Vielleicht kannst Du das mit "git blame" erledigen?

    Christoph, sollte längst im Bett sein