Hallo, ich habe eine externe Festplatte an eine Fritzbox angeschlossen. Auf dieser kann ich über myfritz drauf (auch von aussen) zugreifen. Ist es möglich, auf dieser Festplatte ein Git-Repo anzulegen? Also dass das von überall Clonen und neue änderungen wieder einchecken kann?
:
Verschoben durch Moderator
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.
Kannst du denn per Explorer auf den Ordner zugreifen? Prinzipiell ist es git egal, wo ein Ordner liegt, ob auf einem Netzlaufwerken oder lokal auf der Platte. Oliver
> 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.
c-hater schrieb: > 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. Macht er doch, geht auch garnicht anders. //fritz.box/fritz.nas/ ist die lokale Adresse im Netz für die Laufwerke an einer Fritzbox.
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...
c-hater schrieb: > Weil: es gibt ziemlich viele dieser Fritzboxen... Und alle davon nennen sich lokal "fritz.box". Übrigens ist "box" keine gültige TLD. Dein Argument fällt allein deswegen schon flach. Und das ursprüngliche Problem ist gelöst.
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. Dein Argument fällt allein > deswegen schon flach. Und das ursprüngliche Problem ist gelöst. Hüstel, aber diese gTLD gibt es ja auch erst knapp drei Jahre ... https://www.iana.org/domains/root/db/box.html
Ralf D. schrieb: > Hüstel, aber diese gTLD gibt es ja auch erst knapp drei Jahre ... > > https://www.iana.org/domains/root/db/box.html 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?
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.
Hab MyFritz nie probiert, wenn ich es richtig verstehe, man hat da zuerst einmal nur so ein Webinterface auf seine Daten. Allerdings glaube ich, dass man da auch WebDAV aktivieren kann und in diesem Fall könnte man auch extern, also aus dem Internet, das Git-Repo ansprechen (git clone https://<myfritzurl>/<MyRepoPath>; so in der Art)
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/
Stefan ⛄ F. schrieb: > 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/ Das funktioniert aber nur im Heimnetz, oder? OP will aber "auch von aussen" auf sein Repo.
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...
Stefan ⛄ F. schrieb: > 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. Ich weiß nicht wo du das gelesen hast aber das stimmt nicht. Nur weil du dich bei einem remote git-Repo per ssh authentifizierst und das Protokoll auch über ssh geht, heißt das nicht, dass du keine Helper-Binaries dort brauchst. Du kannst gern versuchen, ein git-repo per ssh von einem Rechner zu klonen, auf dem kein git installiert ist; es geht nicht. Da das schon mit git nicht geht, bezweifle ich es für Subversion noch viel mehr, weil da geht generell kaum was.
Angehängte Dateien:
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.
Stefan ⛄ F. schrieb: > Natürlich geht das. Sogar ohne SSH. Du kannst es lokal ausprobieren, > siehe Screenshot. Stelle dir einfach vor "remote" sei das Netzlaufwerk, > dann hast du es. Hm, ist irgendwo dokumentiert, dass das mit mehreren Benutzern gleichzeitig erlaubt ist? Und mit verschiedenen git-Versionen? Ein bare-Repo auf einem Netzlaufwerk, das mehrere Leute gleichzeitig mounten, finde ich einen ziemlich merkwürdigen Betriebsmodus ... es ist jedenfalls nicht das, was normalerweise gemacht wird.
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"
Na gut, dann bin ich ruhig ;) Für das ssh:// Protokoll brauchst du aber die git helpers auf dem Remote, das war der Fall, den ich im Kopf hatte.
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
Ich hab hier nen kleinen Einplatinen-ARM laufen an dem hängen ein paar Festplatten dran. Und weil der sowieso ständig läuft hab ich ssh von außen zugänglich gemacht. SSH ist der eine Dienst den jeder hat, den jeder braucht, der alles möglich macht. Und selbstverständlich auch git, ohne noch irgendwas anderes zu installieren, wer was anderes behauptet hats einfach noch nie selber probiert. Sowas wie einen "git server" gibt es in diesem Sinne eigentlich überhaupt nicht, es gibt allerdings die Möglichkeit einen ssh-Zugang so zu beschränken daß nur noch git funktioniert und sonst nichts, dann bekommt man keine normale shell mehr, das ist nützlich wenn noch andere außer man selbst dort Zugriff auf Repositories haben sollen. Von der Idee der Fritzbox irgendwelche Spezialaufgaben zu geben (NAS, etc.) außer ihrem eigentlichen Hauptzweck zu dienen bin ich wieder abgekommen: zu verkrampft, zu beschränkt, zu wackelig, zu produktgebunden.
Stefan ⛄ F. schrieb: > 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. Zumindest bei SVN wird dringend davon abgeraten.
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.
Stefan ⛄ F. schrieb: > 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. Das ist nicht der einzige Grund. Siehe https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-repository.html#tsvn-repository-local-share
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.
Die Gründe dafür, svn zu benutzen, sind ohnehin alle schwach. :D
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.