ubuntuusers.de

Hi, gibt es eine Möglichkeit, git-Repos schmerzfrei mit Historie umzuziehen, ich hab da einiges auf verschiedenen Servern, was ich jetzt gerne mit Historie auf einen gemieteten Platz umziehen möchte. Irgendwie stehe ich da auf dem Schlauch.

Servus,

agaida schrieb:

Irgendwie stehe ich da auf dem Schlauch.

ich auch. Da du die Repos einfach klonen kannst und sich die Sache damit gegessen hätte, nehme ich an, dass dein Problem ein ganz anderes ist. Geht es dir um Links auf die Repos? Oder die Verwaltung deiner Remotes? Oder wie oder was? 😀

Frohes Neues. 😉

Dann zieh mal ein Repo von Github nach projectlocker oder noch schlimmer sourceforge. Wenn ich da einfach so Dateien und Verzeichnisse einspielen könnte, hätte ich kein Problem. Aber so von öffentlichem Repo zu öffentlichem Repo hab ich da ein kleines mentales Problem.

Wer lesen kann ist klar im Vorteil. If anything else fail, read the fucking manual. Das hab ich dann noch mal getan und es taten sich Abgründe auf. Sourceforge wird mir immer sympatischer. Die haben so was Edles wie Shellzugriff per ssh auf das eigene Repository im Programm. Ich muss mir das noch mal durchlesen, aber so ein scp ist ja auch schnell mal abgesetzt. Auf jeden Fall ist das Thema damit schon mal fast gelöst.

Erledigt. Eigentlich recht trivial, Git Klonen, nach .git wechseln, nano config, [remote "orign*] löschen. Jetzt der Anleitung folgen:

git remote add origin ssh://USERNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME
git config branch.master.remote origin
git config branch.master.merge refs/heads/master

Now you're ready to push the committed files to our servers:

git push origin master

Ab jetzt tuts auch ein normaler Push. Schade nur, dass der Link zu dieser Anleitung recht versteckt ist, es ist der 2. von insgesamt 2.😉 Falls jemand die Gründe für den Umzug wissen möchte: Ich find halt Trac irgendwie schöner als das Ticket-Tool von github. Die diffs und vor allem patches wirken auch irgenwie erwachsener.

Der beschriebene Weg funktioniert zum Glück auch beim Umzug eines Repositories von Sourceforge nach Projectlocker. Die Git-Unterstütung bei Sourceforge ist momentan das Grauen schlechthin. Für SVN mag das ja alles angehen, da SVN-Benutzer eh nicht so auf Geschwindigkeit stehen. Dass aber ein Trac-Plugin für Git eingebaut ist, welches man sein Monaten nicht wirklich scharfschalten kann, macht das Arbeiten mit Git und Sourceforge nicht grade schöner.

Da ich meine bezahlten Repositories wahrscheinlich eh bei Projectlocker hosten werde, macht es mir auch nichts, meine OSS-Sachen da zu bunkern. Eigentlich schade, aber nicht nutzbares Trac und verkrüppelte Commits (Patches) sind nun wirklich keine Dinge, die ich unkommentiert weiterempfehlen kann. Von der Geschwindigkeit von Trac schweige ich an dieser Stelle mal.

agaida schrieb:

Erledigt. Eigentlich recht trivial, Git Klonen, nach .git wechseln, nano config, [remote "orign*] löschen. Jetzt der Anleitung folgen:

git remote add origin ssh://USERNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME
git config branch.master.remote origin
git config branch.master.merge refs/heads/master

Now you're ready to push the committed files to our servers:

git push origin master

Ab jetzt tuts auch ein normaler Push. Schade nur, dass der Link zu dieser Anleitung recht versteckt ist, es ist der 2. von insgesamt 2.😉 Falls jemand die Gründe für den Umzug wissen möchte: Ich find halt Trac irgendwie schöner als das Ticket-Tool von github. Die diffs und vor allem patches wirken auch irgenwie erwachsener.

Öhm, dieses "origin" ist nur ein Name, eine Konvention zwar, aber dennoch nur ein Name, den du selbst festlegen kannst. Quasi nur ein Shortcut zu einem entfernten Repo. Davon kannst du beliebig viele anlegen. Das ist dann auch nur ne lokale Sache. Beispielweise so:

1

git remote add my_fancy_remote_working_copy <remote repo url>

Du musst den "origin"-Eintrag nicht löschen.

Edit: Ok, so ganz lokal bleibt das wohl nicht. Es könnte sein, dass dieser Name in merge commit messages auftaucht. Allerdings, so sagte man mir im git-IRC-Channel, könnte man alle commit messages selbst verfassen, so dass man potenziell kompromittierende Namen herauseditieren kann. Wie genau das abläuft, weiß ich auch nicht.

Verwirrt sein: Hier mal die config von meinem ehemaligen sourceforge-git. Falls sich jemand umschauen möchte, da stehen momentan nur 2 Dateien drin, sourceforge.git.sucks und project.moved.to.projectlocker.com.

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = ssh://agaida@cmsimplexh-gcom.git.sourceforge.net/gitroot/cmsimplexh-gcom/cmsimplexh-gcom
[branch "master"]
        remote = origin
        merge = refs/heads/master
[branch "agaida"]
        remote = origin
        merge = refs/heads/agaida

In der Anleitung, die gefunden habe, stand eigentlich nur drin, dass dieser [remote "origin"] (natürlich samt Tralala) die Verbindung zu ausserhäusigen Server steuert. Deswegen mein Vorgehen, den Eintrag zu löschen:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[branch "master"]
        remote = origin
        merge = refs/heads/master
[branch "agaida"]
        remote = origin
        merge = refs/heads/agaida

Und ich glaube wirklich nicht, dass das nur lokal gemeint ist und man von diesem Eintrag beliebig viele haben darf. Ich kann mich da aber auch irren.

Es tut mir leid, wenn das jetzt ein wenig garstig rübergekommen ist, aber dieser Mist hat mich jetzt insgesamt knapp 14 Stunden der Zeit gekostet, die ich nicht habe. Ich bin leicht angesäuert. Man möge mir das nachsehen.

Diese 3er-Kombi wird verwendet, um ein existierendes lokales git auf einen existierenden Server, der das hosten soll, raufzuprömpeln. Das war so ungefähr alles, was ich zu diesem Thema im Netz gefunden habe. Also hat Klein-Alfi ein wenig mit Spielzeug für Erwachsene gespielt. Ein leeres Git auf dem entfernten Server angelegt und dann geklont. Dann in einem 2. Verzeichnis mit git init ein leeres Git angelegt. Dann mal Beyond Compare drauf angesetzt und mir die Unterschiede angeschaut 😉. Der einzige Punkt, den ich mit der externen Verbindung in Verbindung bringen konnte, war dieser Abschnitt in der .git/config. So hatte ich das auch gelesen.

Jetzt fehlte nur noch der Schritt, wie man die beiden Teile miteinander verbindet. Das passierte natürlich ganz klassisch mit einem git remote add origin. So weit war mir dass klar. Nur mit dem anlegen der remoten Branch hatte ich ein mentales Problem, da dann meine Kenntnisse von git doch nicht so weit gehen. Und ich war heilefroh, als ich das nach einer Stunde in den Tiefen des Netzes gefunden hatte und es funktionierte.

Und siehe da, es wurde heute noch mal gebraucht. Jetzt habe ich nur noch ein Problem: Projectlocker macht nur private und Arbeitsgruppen-Repositories. Wenn also jemand noch einen bezahlbahren Hoster kennt, der git und trac funktionierend mit offenem Zugriff anbietet - das ist dringend gesucht. Ich kann mir so was auch selbst bauen, das ist aber nicht das Ziel der Übung, dass Zeug soll wirklich extern liegen.

Warum ich so auf trac rumreite - ich muss leider auch noch relativ viel mit SVN machen und ich habe mich einfach an trac gewöhnt. Ich sehe eigentlich nicht ein, warum ich mich bei jedem Projekt auf einen neuen Tracker einstellen soll, wenn der Eine, an den ich mich gewöhnt habe und den ich gut finde, auch für git funktioniert. assembla und sourceforge können es zur Zeit auf jeden Fall noch nicht. Mit Projektlocker bin ich auch nicht wirklich zufrieden, die Buben zerhacken mir mein utf8 in den Patches.

Das war jetz ganz schön viel Text und normalerweise hätt ich tl;dr gesagt, aber du tust mir schon n bisl Leid 😛

Ich hatte übrigens nur ein kleinen Teil deines Problems rausgegriffen, welcher eigentlich gar kein Problem darstellt. Wollte nur einen Hinweis geben. So musst du bspw. gar kein git remote add ... ausführen. Es reicht beim push in deinem Fall zum Beispiel folgendes:

1

git push ssh://USERNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME master

Zu den Sachen mit dem Mergen und Branchen hatte ich nix gesagt, obwohl ich mir ein Umziehen gar nicht so schwer vorstelle. Einfach neueste Revision clonen und ins neue remote Repo pushen.

PS: Es ist nicht gerstig rübergekommen 😉. Und ich kann deinen Gemütszustand voll nachvollziehen.

Der ist gut, muss ich mal probieren. Wirklich angefressen bin ich eigentlich nur wegen trac. Was ausser trac meist abgeliefert wird, ist in meinen Augen unter aller Sau. Eigentlich brauchte ich ja git nur als externes Datengrab, habe mich aber an trac gewöhnt. Das Umziehen davon ist deutlich problematischer.

Ich hab jetzt nur noch ein Problem. Ich möchte nicht auf meinen Komfort verzichten, also git+trac und suche noch einen Hoster für OSS. Sourceforge fällt ja leider wegen nicht können oder wollen raus, assembla, gitorius und github haben kein Trac. Gibts da noch irgendein Projekt, wo dass geht? Geschlossen habe ich das bei Projectlocker und repositoryhosting gefunden, wobei ich repositoryhosting vorziehen würde, rein vom Preis und den angebotenen Leistungen. Die werde ich aber erst nächste Woche testen.

Meinung:

Trac ist Müll. Ich find's extrem unkomfortabel zumal die git-Unterstützung nur sehr rudimentär ist. Github und Gitorious sind sowas wie Trac, bieten es also nicht extra noch an.

dAnjou schrieb:

Meinung:

Trac ist Müll. Ich find's extrem unkomfortabel zumal die git-Unterstützung nur sehr rudimentär ist. Github und Gitorious sind sowas wie Trac, bieten es also nicht extra noch an.

Auch wenn es fast Leichenschändung ist, an dieser Stelle noch was zu schreiben - Vor 2 Monaten habe ich das unkommentiert gelassen, da ich eigentlich ausser Glaubens- und Geschmacksfragen keine Argumente für Trac hatte. Heute habe ich mindestens 2 Gründe, warum Trac geil ist.

Erster Punkt: Das Markup in Trac ist das von MoinMoin. Wer ein MoinMoin-Wiki betreibt, wird ohne Einarbeitung mit Trac zurechtkommen und da was Lesenswertes und gut strukturiertes hinbekommen. Das macht das Arbeiten mit Trac für diejenigen zum Spass, die sich zum Beispiel an MoinMoin oder aber das Marup von UU gewöhnt haben.

Zweiter Punkt: Ich habe ein einheitliches Markup für 3 Wikis, meins, ubunntuusers und Trac. Das ist echt bequem.