[linux-l] Nutzt jemand Git?

Oswald Buddenhagen ossi at kde.org
So Mai 17 00:58:18 CEST 2009


On Sat, May 16, 2009 at 04:23:11AM +0200, Olaf Buddenhagen wrote:
> On Tue, May 05, 2009 at 12:47:03AM +0200, Volker Grabsch wrote:
> > Es gibt Anwendungs-Szenarien, in denen SVN durchaus angebrachter als
> > ein DVCS.
> 
> Glaube ich nicht.
> 
doch: haufenweise faule leute. :D

> > Anders gesagt: Ich habe den Eindruck, dass Git vorrangig für
> > Nur-Pull-Szenarien ausgelegt ist. Push-Szenarien machen mit Git keinen
> > Spaß, aber die hat man auch praktisch nie.
> 
> Aeh? Bei X.org funktioniert es weitgehend problemlos.
> 
> Kannst Du bitte mal erlaeutern, was Dich speziell stoert an git push?
> 
bei große projekten macht das einfach keinen spaß, weil man immer das
pull-before-push-spiel mitmachen muß. also gibt es nur zwei szenarien,
die richtig gut gehen: nur-pull (kernel) und mini-projekte (xorg). bei
qtsw haben wir's aus historischen gründen falsch gemacht ...

> Genau. Der Umstieg auf Subversion lohnt sich einfach nicht.
>
welcher umstieg? ich hab' bei kde nix gemerkt ... ach, moment mal, ich
hab' da ja was mitverbrochen ... :D

> 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.)
> 
das merge tracking in svn ist im prinzip "tagged cherry-picking", also
mit gits nativem ansatz mehr oder weniger grundsätzlich inkompatibel.

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

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

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

> 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 --
>
in der tat.

> 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ß.

> 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".

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



Mehr Informationen über die Mailingliste linux-l