Git Server aufsetzten

Dr. Sommer schrieb:
> https://www.kernel.org/pub/software/scm/git/docs/git-daemon.html

Für den öffentlichen read-only Zugriff ok, zum pushen wegen fehlender 
Sicherheit nicht.

Schau Dir mal gitosis oder gleich gitlab an.

Eine einfache Möglichkeit wäre auch, dem User in der /etc/passwd die 
git-shell als Login-Shell zu geben.

Ich habe alle durch. Nimm gitolite und für git user einen eigenen neuen 
key generieren.
Sonst wirst du wunderbare probleme mit deinen repos bekommen.
Z.b. Klonen geht aber pushen nicht. Niemals den key für deinen ssh 
zugang benutzen.

Gruss Jörg

Der user git hat nur rechte für sich.
 normale loginversuche
Werden von der gitolite shell verhindert.

Sorry vom ipad geschrieben;)

Gruss
Jörg

Wenn es nicht unbedingt git sein muß, bietet sich für Projekte die nicht 
gerade die Komplexität des Linux-Kernels haben (was die Anzahl und 
Hierarchie der Entwickler angeht), u.U. auch fossil 
(http://fossil-scm.org) an.

Das besteht aus einem einzigen Binary von weniger als 2MB und kann 
wahlweise lokal, per SSH, als CGI hinter einem bestehenden Webserver 
oder über einen kleinen eingebauten Webserver angesprochen werden. Neben 
der eigentlichen Versionsverwaltung sind noch ein Bugtracker und ein 
Wiki enthalten, so daß man gerade bei kleineren Projekten dafür keinen 
extra Aufwand treiben muß.

Ich habe den Eindruck, daß sehr oft der Vorschlaghammer git genommen 
wird, ohne darüber nachzudenken, ob nicht ein leichterer Hammer wie 
fossil viel besser zu dem feinen Nägelchen passen würde, das man gerade 
einzuschlagen hat.

Antiexperte schrieb:

> Das ist ja das Schöne an git, man gibt "git init" ein und man hat sein
> Repository und kann seine Versionsgeschichte anlegen, man muss keinen
> Server haben/aufsetzen etc.

Vielleicht ist das falsch rübergekommen, aber auch bei Fossil mußt Du 
keinen Server aufsetzen, wenn Du keinen brauchst: "fossil new" und Du 
hast Dein lokales Repository. Aber die Fragestellung in diesem Thread 
bezog sich nunmal ausdrücklich auf einen Server, deshalb habe ich diese 
Eigenschaften herausgehoben. Im übrigen gibt es selbst beim 
Serverbetrieb von Fossil nicht viel "aufzusetzen".

> git ist dank des kleinen Overheads somit wunderbar auch für
> kleine Projekte geeignet,

Woran machst Du den kleineren Overhead von git denn fest?

Alleine der Kern von git ist knapp zwölf mal so groß ist wie Fossil und 
besteht aus hunderten von Dateien, während Fossil als ein einziges (im 
Grunde installationsfreies) Binary daherkommt:

$ rpm -q --qf '%{SIZE} %{NAME}\n' fossil git-core
1441168 fossil
17032393 git-core
$ rpm -ql fossil
/usr/bin/fossil
/usr/share/doc/packages/fossil
/usr/share/doc/packages/fossil/COPYRIGHT-BSD2.txt
$ rpm -ql git-core | wc -l
767

Dazu kommt, daß git-core (zunindest auf openSUSE) u.A. Perl und Python 
benötigt, die ihrerseits nicht eben klein sind, während Fossil nur libz 
und (optional) openSSL braucht.

> da man keine unnötigen Bugtracker oder Wiki's dabei hat...

Wenn Du sie nicht brauchst, kannst Du sie einfach ignorieren, ohne daß 
Dir dadurch irgendein Nachteil entsteht. Wenn Du sie irgendwann dann 
doch nutzen willst, kannst Du das tun, ohne nochmal zusätzlichen 
Konfigurationsaufwand dafür zu haben.

Einen etwas detaillierteren Vergleich zwischen git und Fossil gibt es 
übrigens hier:
http://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki

Versteh' mich nicht falsch, ich sage nicht, daß git schlecht ist. Es ist 
mit Sicherheit das perfekte Tool für den Linux-Kernel und wurde ja auch 
genau dafür gemacht. Aber es gibt wohl nur wenige andere Projekte, die 
mit dem Kernel vergleichbare Anforderungen an die Versionsverwaltung 
haben, und deshalb sollte man sich beim Start eines Projekts gut 
überlegen, welches Tool am besten paßt, anstatt einfach blindlings git 
zu nehmen, nur weil das alle tun.