[linux-l] Nutzt jemand Git?

[Steffen Dettmer]

* olafBuddenhagen at gmx.net wrote on Sat, May 16, 2009 at 03:51 +0200:
> > 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...

Die meisten müssen bei uns auch nicht so viel mit CVS und den
buildscripten machen. Muß nicht jeder alles wissen sollen. Gibt
Experten für Anwendungen, die möchten jetzt vielleicht nicht ewig
rumlesen und von ihrer `eigentlichen Arbeit abgehalten' werden.
Bei CVS (Kommandozeile) ist das recht einfach: man gibt checkout
-r Kommando vor, zeigt ci und das wars dann schon mehr oder
weniger. Mergen und alles macht einfach jemand anderes. Das ist
mit dezentralen Tools, die ja gerade ermöglichen, dass jeder
alles kann, eher entgegengesetzt angedacht. Aber vermutlich kann
man auch prima Kochrezepte machen, für die, die es jetzt nicht so
interessiert? z.B. ein kleines `add commit push HOWTO' schreiben.

> 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 -- aber man muss sich eben die
> Muehe machen, sie zu lernen.

Eines dieser Grundkonzepte sind meiner Meinung nach `Änderungen,
die man irgendwo hinpackt'. Hier muß man weniger lernen als
vielleicht eher gelerntes vergessen - ich find das jedenfalls
eigentlich logischer als das, was jetzt CVS/SVN machen.

> Dazu kommt, dass Git anders ist. Mercurial und Bazaar versuchen
> weitestgehend SVN nachzubilden, was wiederum versucht weitestgehend CVS
> nachzubilden.

Ist das denn nicht grundfalsch, als changeset-basiertes VCS ein
RCS-frontend nachbilden zu wollen? Warum macht man das? Weil man
annimmt, jeder kenne CVS oder SVN und damit das neue VCS
einfacher wirkt? Was sich am Ende evtl. als Trugschluß
herrausstellen könnte, weil ähnliche aussehende Sachen vielleicht
am Ende gar nicht so ähnlich sind?

> Die Folge von Beidem ist, dass man sich mit Git tatsaechlich ein wenig
> auseinandersetzen muss (d.h. Dokumentation lesen), bevor man anfaengt es
> zu benutzen; an sonsten *muss* es schief gehen. Die meisten Leute wollen
> sich die Muehe aber nicht machen, sondern unbedingt gleich loslegen...

Na ja, man sollte natürlich ne Schulung machen!

> > Kann man da nicht auch einfach ein gemeinsames public repo
> > nehmen?
>
> Freilich kann man.

ahh prima :)

> > 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???
> 
> Wozu Symlinks? "mkdir /tmp/foo && cd /tmp/foo && ~/foo/configure &&
> make"
> 
> Oder meinst Du was anderes?

Nee, das ist genau das.
Symlinks weil... ohh ich muß ausholen.

Man checkt sich da was aus. Das muß man jetzt für sagen wir mal
vier Platformen in je zwei Varianten bauen. Braucht man acht
builddirs. Als Mensch editiert man dann Dateien und kompiliert
neu, ein builddir (das native) kann make check, dann checkt man
ein. Die Scripte, die configure (mit vielen Optionen) aufrufen,
tun dies in einem Unterverzeichnis. Das alles ist auch weniger
unter ~/ (weil NFS -> Netz -> lahm), sondern eher in /tmp (RAID-0
gestript über schnelle 4 Platten -> schnell). Wenn man in
vim/emacs dann `make check' sagt, weiß ein anderer Wrapper, wo es
denn nun hinmuß (also findet via Konventionen aus dem src dir das
builddir).

Eigentlich will ich aber die sourcen unter ~, die builds unter
/tmp aber trozdem zu einem src wissen (ableiten) können, wo das
native builddir liegt. Da wäre ein symlink gut (man hätte dann
einfach ein ~/srcabc/trunk/build/i386-linux zeigt auf
/tmp/irgendwas). Jetzt haben wir meist /tmp/srcabc. Gibt kein
Backup, aber ist ja alles im CVS (Repo wird natürlich
gesichert).

> 
> > 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?!
> 
> Ich bin ziemlich sicher, dass sich beim Wechseln des Branches nur bei
> den Dateien die mtime aendert, die tatsaechlich unterschiedlich sind...
> 
> Aber das hilft Dir natuerlich nicht, wenn sich eine Datei aendert, die
> ein Neubauen von allem erzwingt. Da kann Git auch nix machen. Keine
> Ahnung was Du Dir da vorstellst.

Na ja, bei CVS hilft ein ~/srcabc/trunk usw. Das ginge mit Git ja
auch (müßt man halt verschiedene Repos haben und rumrullen
müssen).

Hat denn noch nie jemand darüber nachgedacht, autoconf und git
zusammen zu benutzen? Das kann doch so exotisch nicht sein?

> > 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.
> 
> Das ist eins der Oben erwaehnten Grundkonzepte, die man verstehen muss,
> um Git richtig benutzen zu koennen...

Ahh ja, das steht auch so im Handbuch, hab ich gerade gelesen,
ja.
Wobei mir bei näherem Überlegen aufgefallen ist (falls ich nicht
falsch liege), dass das eigentlich auf das gleiche hinauskommt,
weil ja der komplette tree eh bekannt ist. Da kann man eines
natürlich aus dem anderen ableiten. Ich ging davon aus, dass man
nur Änderungen speichert (Platz), aber das hat ja hiermit nichts
zu tun. Man kann es irgendwie speichern und anders nutzen und
identifizieren, weil es ja auseinander ableitbar ist.
(eigentlich hab ich das auch schon ein bißchen gewußt, weil man
ja die hashes wie branches und tags benutzen kann, z.b. bei git
diff).

den Hash kann man aber nicht als $Name$ nehmen, weil zwei genau
gleiche Stände (in verschiedenen Branches/repos) den gleichen
Hash haben. Wobei das Problem möglicherweise nur genau dann zum
Problem wird, wenn man das wissen sollen muß - weil das unlogisch
ist?
Junio C Hamano schrieb in
http://article.gmane.org/gmane.comp.version-control.git/44754

Having reiterated what Linus already said why keyword expansion
and git are not friendly with each other (perhaps the reason is
because the former is stupid and git is smart),

:-)

nach noch ne Weile google...:
Kann es sein, dass das einfach nicht geht?

> > Selbst bei einem Tag muss man ja dazu schreiben, wo es gilt (oder?).
> 
> Richtig, Tags sind im Prinzip nur lokale Namen fuer bestimmte Commits.
> Wenn man eine global eindeutige Kennung braucht, muss man die sha1
> direkt angeben, statt dem symbolischen Namen...
> 
> Wenn Du die sha1 in der Datei mitschickst, weiszt Du immer ganz genau wo
> sie herkommt.

Nein, doch eben gerade nicht!

oki,

Steffen

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