[linux-l] Nutzt jemand Git?

[Marian Rudzynski]

Steffen Dettmer wrote:
> Hi,
>
> nutzt hier eigentlich jemand Git (DVCS)?
> Vor ein, zwei, drei, ... Jahren gabs ja hier mal einen mercurial
> Thread. Hab jetzt bisschen was über Git gelesen und bin
> begeistert. Allerdings ist das natürlich alles viel zu
> theoretisch :) Bei meinen kleinen Tests sah jedenfalls alles
> Klasse aus. Allerdings hab ich Fragen.
>
> Hat jemand praktische Erfahrungen in grösseren Projekten? Im
> Kernel läufts ja wohl gut, sonst hätten sie es anders gemacht :)
>
>   
Wurde sogar extra fuer den Kernel entwickelt.
> Migriert heute eigentlich noch jemand zu SVN oder nimmt man
> gleich Git? Oder mercurial oder Bazar? Darcs eher gar nicht?
>
>   
Das kommt auf dein Projekt und deine Arbeitsweise an. Ich tendiere 
immernoch eher zu Subversion einfach weil ich nur Projekte habe die 
wenige (<100.000) Files umfassen und ich zentralisierte Repositories 
lieber mag - allein schon um alleinige Zugriffskontrolle zu haben.

Git ist ideal fuer dezentralisierte Entwicklerteams von grossen 
Projekten (viele, nicht grosse Files ..fuer grosse Files dann doch 
lieber Subversion)
> Ü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).
>
>   
Siebe oben. Und der grosse Bulk an Pro-Git-Artikeln die so auftauchen 
sind von Ruby on Rails Evangelisten die einfach generell begeistert von 
jeder neuen Technologie sind und sie so lange zweckentfremden bis der 
naechste leuchtende Hype daher kommt.

Subversion wird ausserdem weitgehend als der Nachfolger von CVS 
angesehen und macht imho CVS gaenzlich ueberfluessig.
> Praktisch interessiert mich aber, ob Git in der Praxis auch für
> `nicht-Freaks' nutzbar ist (z.B. für outsourced development). Ich
> persönlich fand (nach Doku, praktische Erfahrungen habe ich ja
> nicht) es eigentlich einfach. Klar, man muss sich darauf
> einlassen, aber dann gibt es viele Features, die ich mir bei CVS
> und SVN (was ich kaum nutze) schon immer gewünscht habe.
>
>   
Git ist sehr viel komplizierter zu verwenden als Subversion. Deshalb 
findest du auch millionen von "hier ist meine .profile mit 40 git 
aliasen"-Blogposts fuer den unwissenden Mac User, der gerne jede Zeile 
die er eingeben soll komplett vorgekaut vorfindet.

Aber mit wenigen Handgriffen kannst du Git vor allem ohne zentralen 
Server verwenden, was es sehr viel "Einsteigerfreundlicher" macht.

Wenn du Git einfach mal ausprobieren moechtest kannst du dir einen 
Account auf Github.com erstellen und ein beliebiges Projekt forken um 
damit rum zu spielen.
> 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? Mit CVS arbeite ich i.d.R. auf Sandboxes in /tmp. /tmp
> ist (bei mir) meist ein schnelles RAID-0 (oder sowas). backup
> brauch ich da nicht, weil ich ja oft einchecke und Repo wird
> gesichert. Das finde ich elementar. Die build Sandboxes sind
> oft riesig (300.000 - 1 mio lines mit C++ Debugsymbolen sind
> schnell mehr als 2 GB - pro Sandbox).
> Ich hätte also gern mindestes für Backups eine Art `zentrales
> Repo'. Das `zentrale Repo' aus build-Sicht (wenn man CVS:GIT wie
> 1:1 mappt :)) wäre IMHO das Arbeitsreprository des Integrators.
> Das meine ich jetzt nicht, sondern eines, was "alles wichtige"
> hat.
>
> Ist der Ansatz falsch (weil eben gar nicht distributet)? Wie
> macht man backups bei Git? 
>
>   
Git hat kein Repository wie du es von CVS oder SVN gewohnt bist. Du 
committest direkt in deiner working copy und "pushst" diese commits an 
eine Gegenstelle (einen anderen Computer, einen zentralen Server der als 
"Repository" agiert, etc.) und kannst von anderen commits "pullen".

Alles wird direkt in deiner eigenen working copy, im Filesystem verwaltet.

Ein Backup machst du also mit tar -cjf working_dir.tar.bz2 working_dir ;)

> 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???
>
> 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>).
>
> 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).
>
> Das müsste doch ein Standardproblem sein, aber ich fand da nichts
> wirklich hilfreiches. Gut, bei einem 10 KLOC project ist's egal,
> aber da reicht auch CVS oder gar ein SVN, aber bei grösseren
> dauert ein make check dann ja nicht 60 Sekunden sondern 15-30
> Minuten pro Branch (auf schnellem Linux; unter cygwin wirds noch
> viiiiel schlimmer). Wie geht man damit um?
>
>   
Ich verwende Git bisher auch nur fuer Ruby on Rails Kram, aber du kannst 
davon ausgehen dass wenn es fuer den kernel verwendet wird, die 
timestamps korrekt sitzen. Erfahrungswerte habe ich da aber null.
> 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? Da
> gibts ja rein logisch keine globale ID für Versions-Stände (wohl
> aber für Änderungen, aber das hilft ja nicht). Selbst bei einem
> Tag muss man ja dazu schreiben, wo es gilt (oder?).
>
> Sorry für die lange Mail. Wenn jemand ein zwei Fragen beantworten
> könnte (z.B. durch einen geeigneten Link), wäre das Klasse :-)
>
>   
Kein Schimmer was man in Git da macht aber in Subversion hast du fuer so 
etwas hooks. Google Subversion+Hooks.

> oki,
>
> Steffen
>
>