[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