Git Repository auf externe Festplatte an Fritzbox möglich?

Wenn mit "überall" das LAN gemeint ist, müsste das schon mal gehen. Die 
Fritzbox stellt den Platteninhalt über Samba bereit.

1

$ git clone /X/Pfad/zum/Repo.git

X ist dein eingebundenes Netzlaufwerk.

Bob schrieb:
> Wenn mit "überall" das LAN gemeint ist, müsste das schon mal gehen. Die
> Fritzbox stellt den Platteninhalt über Samba bereit.

Von überall meinte ich auch eigentlich außerhalb meines Heimnetzwerkes.

Aber hier würde ich es zunächst mal probieren.

Habe jetzt auf der Festplatte einen Ordner angelegt. Wenn ich jetzt auf 
meinem pc aber
git clone N:\Seagate_HDD\Private\Coding\NeuronalNet mache, bekomme ich 
den Fehler

fatal: 'N:Seagate_HDDPrivateCodingNeuronalNet' does not appear to be a 
git repository
fatal: Could not read from remote repository.

> git clone N:\Seagate_HDD\Private\Coding\NeuronalNet mache, bekomme ich
> den Fehler
>
> fatal: 'N:Seagate_HDDPrivateCodingNeuronalNet' does not appear to be a
> git repository

Probiers mal mit / statt \.

foobar schrieb:
> Probiers mal mit / statt \.

Das war ein teil des Fehlers.
Der andere war: ich durfte nicht N:/... sonder //fritz.box/fritz.nas/...

jetzt läuft es.

Danke

Michael schrieb:
> Habe jetzt auf der Festplatte einen Ordner angelegt.

Mit 'git init'? Ansonsten ist es doch kein Wunder, dass sich git 
beschwert:

Michael schrieb:
> does not appear to be a
> git repository


Tipp: Lass' den ganzen Netzwerkquatsch erstmal weg. Entweder benutzt du 
Infrastruktur, die dir jemand zur Verfügung stellt, oder du verwendest 
git zunächst nur lokal. Sobald dir der Workflow vertraut ist und du die 
Begriffe verstehst, kannst du dir dann Gedanken machen, wie man git 
sinnvoll hostet.

Michael schrieb:

> Von überall meinte ich auch eigentlich außerhalb meines Heimnetzwerkes.

Dann ist der beste Weg: VPN. Dann bist du von überall in deinem 
Heimnetzwerk.

Rene K. schrieb:

> Macht er doch, geht auch garnicht anders.

Hoffentlich...

> //fritz.box/fritz.nas/ ist die
> lokale Adresse im Netz für die Laufwerke an einer Fritzbox.

Oder eine gültige Adresse in der öffentlichen Domain fritz.box, die 
NICHT AVM gehört und selbst wenn sie das täte, keinesfalls korrekt auf 
die nur lokal gültige Adresse von fritz.box aufgelöst werden könnte...

Weil: es gibt ziemlich viele dieser Fritzboxen...

Gitinator schrieb:
> Tipp: Lass' den ganzen Netzwerkquatsch erstmal weg. Entweder benutzt du
> Infrastruktur, die dir jemand zur Verfügung stellt, oder du verwendest
> git zunächst nur lokal. Sobald dir der Workflow vertraut ist und du die
> Begriffe verstehst, kannst du dir dann Gedanken machen, wie man git
> sinnvoll hostet.

Eben - eine echte Versionsverwaltung erfordert Software die irgendwo 
laufen muss. Für Dich alleine würde es ja ein RasPi in Deinem Netz schon 
tun. Ob dieser dann die Daten aus einem Share in Deinem Netz oder von 
einer Festplatte an seinen Anschlüssen schaufelt ist ihm egal.

S. R. schrieb:

> Übrigens ist "box" keine gültige TLD.

Du bist so dermaßen von vorgestern, dass selbst Schweine nicht mit dir 
diskutieren wollen würden...

c-hater schrieb:
> Du bist so dermaßen von vorgestern, dass selbst Schweine nicht mit dir
> diskutieren wollen würden...

Jetzt rutscht dein Niveau (wenn man es überhaupt so nennen kann)
wieder in den Keller.
Du bist wirklich im Tiefflug durch die Kinderstube geflogen, oder?

SVNfan schrieb:
> Eben - eine echte Versionsverwaltung erfordert Software die irgendwo
> laufen muss.

Das ist nicht korrekt. Für Git, Subversion und Mercurial braucht man 
keine spezielle Software auf den Server, sondern lediglich ein 
Netzlaufwerk/Verzeichnis auf dass die Entwickler gemeinsam Zugriff 
haben.

Das Webinterface ist nur Spielkram. Die FritzBox stellt auch ein 
richtiges Netzlaufwerk zur Verfügung: 
https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publication/show/543_Speicher-NAS-am-Computer-als-Netzlaufwerk-einrichten/

Für git gibt es die —bare Option für Serververzeichnisse, da muss dann 
nichts im Arbeitsverzeichniss liegen.
https://blog.seibert-media.net/blog/2014/12/29/tutorial-git-aufsetzen-teil-1-git-init/

Luther B. schrieb:
> Das funktioniert aber nur im Heimnetz, oder?

Ich hab's nur vom Heimnetz aus probiert. Ob es auch remote geht, weiß 
ich nicht.

Bernd K. schrieb:
> Und deshalb ist das Hijacking dieser TLD durch die Fritzbox nicht
> statthaft. Was wenn eine wichtige (oder auch unwichtige, ganz egal)
> Webseite unter der offiziellen Domain fritz.box zu finden wäre und alle
> Besitzer von Fritzboxen wären daran gehindert diese jemals aufzurufen?

Der Vollständigkeit halber noch, die offizielle special use Domain für 
Heimnetzwerke ist home.arpa. Siehe auch: 
https://tools.ietf.org/html/rfc8375

Luther B. schrieb:

> Das funktioniert aber nur im Heimnetz, oder? OP will aber "auch von
> aussen" auf sein Repo.

Na, dann muss er halt ein VPN zum Heimnetz aufbauen. Das war schon vor 
einem Jahr die beste Lösung (nachdem der hl. Stefanus diese 
Thread-Leiche wiederbelebt hat) und ist auch heute noch die beste 
Lösung.

Am Sachverhalt selber hat sich nämlich in diesen Jahr rein garnix 
geändert...

Und der ist: Die Fritzbox kann eine SMB(V1)-Freigabe bereitstellen. Die 
läßt sich problemlos auch als Ablageort für ein Git-Repository benutzen. 
Denn mehr ist dafür tatsächlich nicht nötig. Das war der einzig 
sinnvolle Beitrag vom hl. Stefanus. Hätte er vor einem Jahr auch schon 
äußern können, wußte er damals aber vermutlich selber noch nicht...

Wie auch immer: Nur ein Vollidiot würde diese Freigabe exponieren (d.h.: 
direkt im Internet bereitstellen). Sowas hält man schon abgeschirmt im 
LAN und greift eben nur durch einen VPN-Tunnel darauf zu.

Jaja, es hat schon seine Gründe, dass aktuelle Windows-Versionen per 
default nichtmal im LAN mehr auf solche Freigaben zugreifen mögen...

Das ist keine Schikane oder geplante Obsoleszenz. Das hat ganz sachliche 
Sicherheitsgründe. Und, bevor die Linux-Fanboys jetzt in Jubelstürmen 
ausbrechen: bei NFS sieht es kaum anders aus. Nur die Versionsnummern 
sind natürlich nicht identisch...

Sven B. schrieb:
> Du kannst gern versuchen, ein git-repo
> per ssh von einem Rechner zu klonen, auf dem kein git installiert ist;
> es geht nicht.

Natürlich geht das. Du kannst es lokal ausprobieren, siehe Screenshot. 
Stelle dir einfach vor "remote" sei das Netzlaufwerk, dann hast du es.

Ich weiß mit 100% Sicherheit, dass es mit Subversion und Mercurial auch 
so geht. Ich habe mit den beiden Programmen 10 bzw. 5 Jahre  Erfahrung 
aus täglicher beruflicher Benutzung.

Sven B. schrieb:
> Hm, ist irgendwo dokumentiert, dass das mit mehreren Benutzern
> gleichzeitig erlaubt ist?

Keine Ahnung ob das irgendwo steht, aber es geht. Das ist bei allen mir 
genannten Source Repositories eine Selbstverständlichkeit.

In der Firma greifen wir über SSH auf das Repository zu. Dafür ist auf 
dem Server nur der OpenSSH Daemon installiert - kein Git Daemon. Auch 
das kannst du ganz fix lokal ausprobieren.

Ich habe gefunden wo das steht: 
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols

"The most basic is the Local protocol, in which the remote repository is 
in another directory on the same host. This is often used if everyone on 
your team has access to a shared filesystem such as an NFS mount"

Sven B. schrieb:
> Für das ssh:// Protokoll brauchst du aber die git helpers auf dem
> Remote, das war der Fall, den ich im Kopf hatte.

Ist mir nicht bekannt. Was für "helper" sollen das sein?

Nachtrag: Ich habe das gerade auf dem Laptop meiner Frau ausprobiert. Es 
wird ein Binary mit dem Namen "git-upload-pack" benötigt. Ohne dieses 
geht Git tatsächlich nur über Netzlaufwerk, nicht über SSH.

Eigentlich muss man nur eine Remote Shell per ssh aktivieren, das macht 
man aber unabhängig von git sowieso weil es sinnvoll ist.
Der Vorteil von svn/mercurial/git gegenüber cvs oder gar source safe ist 
ja gerade das man dezentral auch die ganze Historie hat.
Für große Teams und Repos machen die Server für git schon Sinn für den 
ganzen CI oder Build Server Automatismus.
Edit: zu langsam am Smartphone getippt

Rolf M. schrieb:
> Zumindest bei SVN wird dringend davon abgeraten.

Weil SVN die Dateien bei direkter Zugriffsmöglichkeit nicht vor 
mutwilliger Zerstörung beschützen kann. Im lokalen Netz mit 
vertrauenswürdigen Entwicklern kann man den Sinn des Schutzes gerne in 
Frage stellen. Bei Zugriff über das Internet sicher nicht mehr.

Das betrifft Mercurial, Git und CVS (habe einen vergessen?) natürlich 
ebenso.

Rolf M. schrieb:
> Das ist nicht der einzige Grund. Siehe ...

Naja, der zweite Grund ist aber schwach, weil sowohl NFS als auch SMB 
das notwendig Locking unterstützen.

Der dritte Grund ist auch schwach. Weil sowieso alle Team-Mitglieder 
irgendwo gemeinsamen Zugriff auf Dateien brauchen. Also kann man die 
dazu nötige Konfiguration als bereits vorhanden betrachten. Sie ist auch 
keineswegs kompliziert.

Ich akzeptiere nur den ersten Grund. Und der wiederum ist schwach, 
solange man sich gegenseitig vertraut. Was hoffentlich eine 
selbstverständlichkeit ist. Ist es jedenfalls überall, wo ich bisher 
tätig war.

Wir nutzen in der Firma SSH, weil es für alle Beteiligten an einfachsten 
ist. Denn SSH brauchen wir ohnehin zum Login auf all unsere Server.