[linux-l] Nutzt jemand Git?

[Volker Grabsch]

olafBuddenhagen at gmx.net <olafBuddenhagen at gmx.net> schrieb:
> On Tue, May 05, 2009 at 12:47:03AM +0200, Volker Grabsch wrote:
> 
> > 2. Wenn es wider Erwarten gute Gründe dafür geben sollte, nimm besser
> > _nicht Git_ dafür. Das Verhalten von "git push" ist m.E.n. hochgradig
> > kontra-intuitiv. Nimm stattdessen Mercurial oder Darcs, denn "hg push"
> > bzw. "darcs push" tun genau das, was man erwartet.
> > 
> > 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?

Kurz zur Klarstellung: Wenn ein "bare"-Git-Repository vorhanden ist,
und man regelmäßig einen Push dorthin macht, ist alles okay. Aber das
ist auch das einzige, wofür man "git push" benutzen kann, und das
gehört genau genommen zum "Pull"-Szenario.

(d.h. jeder User hat ein Remote-"bare"-Repository in das er einen
Push macht, und aus dem andere User "pull"en)

Problematisch wird es, wenn ich einen Push in ein Arbeits-Repository
mache. Dort wird der Push nämlich komplett in die Versionsverwaltung
aufgenommen, aber die lokalen Dateien bleiben unverändert und werden
plötzlich mit der neuen (ge"push"ten) Version verglichen. Wenn man nun
vom Arbeitsverzeichnis aus einen Commit macht, committet man nicht
nur seine lokalen Änderungen, sondern macht effektiv auch den gesamten
Push wieder rückgängig. Ohne Warnung oder sonstiges.

Und da es ein neuer Commit ist, werden andere, die aus diesem
Repository einen "Pull" ziehen, ebenfalls plötzlich wieder die
Änderungen des "Push" verlieren.

Ich habe kein Git-Spezialkommando gefunden, mit dem man das Problem
beheben kann. Aber selbst wenn es eines gibt, bleibt die Kritik: Es
ist komplett kontra-intuitiv, denn bei "normaler" Arbeitsweise beim
nächsten Commit wird der Push dauerhaft zunichte gemacht - durch
einen neuen Changeset, der genau die Änderungen des "push" wieder
zurück ändert.

An dieser Stelle verhalten sich Darcs und Mercurial wesentlich
intelligenter!

> > Wenn ihr einen Integrator habt, sollte dieser regelmäßig aus allen
> > anderen Repositories "pull"en. Ich halte es für keine gute Idee, dass
> > die Entwickler ungefragt ins Repository des Integrators ihr Zeug
> > hinein-"push"en können.
> 
> Sehe da kein Problem... Man kann auch ein zentrales Repository haben, in
> das die Leute nur jeweils in ihre eigenen Branches pushen.
> Repository-Hierarchie und Branch-Hierarchie sind bei Git (im Gegensatz
> zu einigen anderen DVCS) voellig orthogonal. Einer der groszen Vorteile.

Mercurial und Darcs machen es sich in dem Punkt einfacher. Sie
sagen, jedes Repository ist ein Branch, d.h. wer einen neuen
Branch aufmachen will, legt dafür ein neues Repository an. Wenn
das Repository auf Serverseite auch nur ein Verzeichnis ist,
das unbürokrastisch angelegt und gelöscht werden kann, hat das
auch seine Vorzüge.

Zumindest bei lokalen Arbeiten habe ich diese Branch-Funktionalität
noch nicht vermisst, da ich für neue Branches eh ein separates
Arbeitsverzeichnis anlege.


Dennoch ist es ein nettes Feature von Git, und wer es benötigt bzw.
sehr zu schätzen weiß, für den ist das auf jeden Fall ein Grund für
Git und gegen Mercurial/Darcs.

Wer hingegen einen "push" in andere Arbeits-Verzeichnisse machen
möchte (ich habe einen konkreten Anwendungsfall dafür), der sollte
die Finger von Git lassen und lieber Mercurial oder Darcs nehmen.


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR