[linux-l] Nutzt jemand Git?

[Steffen Dettmer]

* Oswald Buddenhagen wrote on Sun, May 17, 2009 at 00:58 +0200:
> > git-cvs ist uebrigens nicht sonderlich gut. Es gibt einige anderen
> > Import-Tools, die wohl viel mehr fressen koennen...
> > 
> zum bleistift cvs2svn, was neuerdings auch cvs2git und cvs2hg mitbringt.
> *das* importtool schlechthin ...

Verstehe ich das richtig, dass git-cvs intelligent Changesets
importiert (via cvsps), nur read-only-Zugriff braucht und
inkrementell funktioniert, cvs2git hingegen nicht, direkt aufs
Filesystem muß und es sogar ändert? Was ist daran besser?

> > > 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...
> >
> nun, ich bin mir nicht sicher, ob ich auf arbeit nur von idioten oder
> faulen säcken umgeben bin, aber irgendwie kriegen es viele doch nicht
> auf die reihe ...

Ja, sowas würde ich auch befürchten. Soll auch nicht jeder
sonstwieviel Zeit investieren müssen. Vielleicht sind das da
weder Idioten noch faule Säcke, sondern Leute, die sich einfach
nur auf ihr Thema konzentrieren!

> > Wenn man hingegen die Grafik-Designer oder so dazu bringen will,
> > Versionskontrolle zu verwenden, koennte man eventuell ueberlegen, was
> > Anderes zu nehmen.
> >
> die gnomer haben dazu ne untersuchung gemacht ... mit leicht
> überraschenden ergebnissen.

Was heißt das, dass Grafik-Designer dann Versionskontrolle
lieben?

> > aber man muss sich eben die Muehe machen, sie zu lernen.
> >
> jo, und die widerstände an dieser stelle sind absolut *enorm*. es ist
> unglaublich, gegen was für eine stopp-kraft man in einem unternehmen mit
> 100 programmieren ankämpfen muß.

Ja, selbst bei 10 Entwicklern muß das nicht einfach sein. Es
muß ja nichtmal richtig sein - hängt ja auch von vielen Faktoren
ab.
Hast dazu weitere Informationen? Links oder so?

> > Die meisten Leute wollen sich die Muehe aber nicht machen, sondern
> > unbedingt gleich loslegen...
> > 
> um genau zu sein, fühlen sich viele persönlich angegriffen und maulen
> was von perforce-war-so-schön und "steine in den weg werfen".

(was ich zum Teil verstehen kann - viele wollen vielleicht die
Aufgabe mit möglichst wenig Overhead lösen, und wenn z.B. SVN
reicht, warum sollen sie sich denn von einer Migration bremsen
lassen?).

> > > 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.
> > 
> jo ... außer man will rebase verstehen ... :D

Kennt Git denn Staende? Dachte, es würde /Änderungen/ kennen?
Stände ergeben sich dann ja nur daraus, wie man die Änderungen
jetzt gerade hintereinander ausführt (was sich u.U. - rebase und
andere - ja ändern kann).
Wenn ich es richtig verstanden habe, und Git in Änderungen denkt,
dann ist sowas wie CVS's $Name$ konzeptionell ja gar nicht
unbedingt drin (bzw. wäre dann höchstens eine lange Liste
aller Änderungen).

oki,

Steffen

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