[linux-l] Nutzt jemand Git?

Steffen Dettmer steffen at dett.de
So Mai 17 18:26:58 CEST 2009


* Volker Grabsch wrote on Sun, May 17, 2009 at 09:28 +0200:
> > 
> > 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)

Nein, denn man kann doch auch ein Remote-"bare"-Repository für
alle haben. Da geht ja dann auch nur dieses fast-forward-push.

> Problematisch wird es, wenn ich einen Push in ein Arbeits-Repository
> mache. 

Du meinst mit "+"-refspec? Sonst werden nicht-fast-forward pushes
doch abgelehnt, oder?
So wie ich es verstanden hab, pusht man nur in nicht-eigene
bares, da ist receive.denyNonFastForwards default und es kann
nichts passieren, oder verwechsel ich da was?

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

CVS und SVN kann man auch so benutzen, dass man so ein Problem
bekommt ;-)

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

ist das denn nicht
git-config receive.denyNonFastForwards true
?

Aber klar, wer force und + kann, kann da auch 
git-config receive.denyNonFastForwards false
sagen :)



Aber echt, mich würde mal interessieren, warum es sowas überhaupt
gibt. Warum ist receive.denyNonFastForwards nicht das einzig
mögliche?

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

Ich habe gelesen, dass diese Arbeitsweise meist wohl immer dann
genutzt wird, wenn einen das [D]VCS dazu zwingt (ich hab bei CVS
und SVN auch immer ein workdir pro Branch, wegen config.h mit
Versionsnummer).

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

... oder Git benutzen, wie es gedacht ist, nämlich über ein bare repo :)

oki,

Steffen

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



Mehr Informationen über die Mailingliste linux-l