[linux-l] Nutzt jemand Git?

[olafBuddenhagen at gmx.net]

Hallo,

On Fri, May 08, 2009 at 12:43:17AM +0200, Steffen Dettmer wrote:
> * Christoph Biedl wrote on Tue, May 05, 2009 at 01:42 +0200:
> > Steffen Dettmer wrote...

> > 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).
> 
> Jaaaaaaaa, das klingt schon wieder so, als ob Git nix für ne Firma
> wäre... Oder ist das ein Spezialfall, der einfach mit abfällt?

Ich finde Git extrem flexibel. Ich benutze es selbst bisher
hauptsaechlich fuer mein Diplomprojekt (nur lokales Repository, keine
Branches) und ein Wiki (zentrales Repository, ebenfalls keine Branches)
-- von weit verteilt also keine Spur. Und selbst in diesen trivialen
Anwendungsfaellen merke ich immer wieder, wie sehr Git mir die Arbeit
erleichtert...

Ich kann mir kein Szenario vorstellen (vorausgesetzt es geht um
Quellcode-Verwaltung, nicht irgendwelche anderen Sachen), fuer das Git
nicht gut geeignet waere.

> Wir haben sogenannte Systeme. Das sind ganz kleine CVS module, da
> steht im Wesentlichen eine Liste der zu verwendenen CVS-Module drin
> (Repo, Modulname, Modulverzeichis, Branch, Zielverzeichnis) und
> Administratives. Dann gibts ein Skript das die Sourcen holt. Das Tolle
> ist: man kann dann dort oder in irgendeinem Unterverzeichnis ganz
> normal CVS benutzen. Es funktioniert einfach. Man merkt von den
> Repo-Grenzen nichts. Toll! Für SVN wurden von einem Kollegen mal
> diverse Skripte angefangen, die das emulieren, aber so richtig toll
> war das alles nicht.
> 
> Wie macht man das mit git?

Ich verstehe Dein Szenario ehrlich gesagt nicht so ganz... Aber es
klingt nach einem Fall fuer "git submodule".

Das funktioniert etwas anders als geschachtelte CVS-Repositories: Bei
einem Commit wird nicht automatisch in die Unterrepositories comitted.
Wenn man in einem Unterrepository was aendert, muss man das zunaechst
dort commiten. Im Haupt-Repository wird dann vermerkt, in welchen
Versionsstaenden die Unterrepositories jeweils eingebunden werden.

Das ist in den meisten Anwendungsfaellen tatsaechlich nuetzlicher als
das CVS-Verhalten...

> > 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 
> 
> Warum sollte man den Entwicklern einen Clienten vorschreiben? Ich
> glaub, bei uns nehmen alle fast nur Kommandozeilen CVS, weil die GUIs
> alle immer irgendwelche Probleme haben

Was er wohl meinte ist, dass die Leute dann lokal irgendwas anderes
benutzen koennen: z.B. Git ueber git-svn...

Den Vorschlag gab es in einem Projekt, an dem ich etwas beteiligt bin,
auch. Ich war dagegen. Auch wenn alle modernen Systeme sich mit
Subversion austauschen koennen, kann ich mir nicht vorstellen, dass das
wirklich gut funktioniert. Man kann einfach nicht alles umsetzen, wenn
der zentrale Server viel weniger kann als die "Clients"... (Vor allem da
Subversion ja bis vor Kurzem nicht einmal Merge-Tracking hatte -- die
Informationen fehlen dann einfach.)

> > - 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.
> 
> Ohh, was erzeugt da Trümmer? Ich wollte mal mit git-cvs rumspielen,
> ist dann wohl keine gute Idee?

Naja, git-cvs ist nicht wirklich vergleichbar, da es ja praktisch nur
Importieren kann -- waehrend git-svn in beider Richtungen funktioniert.

git-cvs ist uebrigens nicht sonderlich gut. Es gibt einige anderen
Import-Tools, die wohl viel mehr fressen koennen...

-Olaf-