git repository frage

D

das.chaos

Guest
hi,

bevor ich mich als inkompetent oute (obwohl mir nichts peinlich ist, lol)... erst wenn die Notwendigkeit gegeben ist, dann beschaefitige ich mich mit Dingen :) wie z.B mit Git.

Meine Frage bezieht sich auf in
>
> http://splbio.wordpress.com/2012/11/24/basing-a-commercial-product-on-freebsd-using-git/
>
dargestellten Loesungsansatz. soweit so gut. Da ich es langsam leid bin via Modus Operandi Copy & Paste zu wirken, reifte bei mir die Erkenntnis eine Versionsverwaltung zu installieren.

Wenn ich bspw. mit dem FreeBSD Kernel experimentiere, wie z.B. hier
>
> http://wiki.bsdforen.de/howto:exper...n_multi_protocol_label_switching_mpls_freebsd
>
was ich verbrochen habe :). Nun, die eigendliche Frage...

Muss ich innerhalb dem Repository (git) die exakte Verzeichnisstruktur (/usr/src/sys/...) des Quellcodebaumes bzgl. zu pachender oder veraendeter bzw. ergaenzter Dateien abbilden oder ist da ein gewisser Freiraum, wenn ich den trash auf einer Hostingplattform veroeffentlichen will? Ist eigendlich eine selbsterklaerende Frage, aber da bin ich mir momentan nicht wirklich so sicher.... mangelns Erfahrung mit git.
 
Vielleicht steh ich grad aufm Schlauch, aber ich verstehe nicht ganz worauf du hinauswillst. Kannst du das vielleicht an nem Beispiel erörtern?
 
Ok....

momentan arbeite ich mit einer lokalen Kopie des Quellcodes aus /usr/src/sys, welcher ergaenzt wurde um das Verzeichnis ./netmpls bzw. net wurde um if_mpe.c erweitert, ferner sind Dateien aus ./net gepached worden bzw. wurde ./netinet/if_ether.c gepached. Die Frage ist, wenn ich ein Repository mir mit Git baue, muss ich bspw. die exakte Struktur:
# .../src/sys/net/...
# .../src/sys/netinet/...
# .../src/sys/netmpls/...
innerhalb des zu erstellenden Repositories als absolute Pfade bspw /usr/src/sys/bla/blubb darstellen oder genuegen auch relative? Ziel des ganzen ist es, dass bei git clone der Quellcode inklusive gepachter Makefiles in /usr/src/sys/... kopiert wird und wenn Aenderungen geschehen sind, dass bei Commit o.g. Baumstruktur gegeben ist. IIrgendwie so halt :). Das Repository soll nur die Dateien (inkl. Verzeichnisse) enthalten, die bzw. in den aufs Wiki verlinkten Content (der C Quellcode) beschriebenen.

Edit: sorry fuer die grauenfvolle Orthographie, ich leide seit meiner Kindheit unter einer schweren Form von Legasthenie (lese-/Rechtschreibschwaeche), dafuer kann ich nichts
 
Zuletzt bearbeitet von einem Moderator:
Ich bin immer noch nicht ganz sicher, dass ich genau verstanden habe, was du meinst. Generell erzeugst du in einem Verzeichnis ein git repository mit git init oder klonst eines in ein Verzeichnis rein mit git clone.
Wenn du jetzt den Code in /usr/src hast kannst du da ein repository erstellen. Wenn das irgendwo anders hingeklont wird werden die ganzen Verzeichnisse und Dateien relativ zum Stammverzeichnis (in dem das .git-Verzeichnis liegt) mitgeklont. Das Repository interessiert sich nicht dafür, wo es selbst liegt. Hilft das oder meinst du was ganz anderes?
 
Danke,

genau das meinte ich. Bevor ich loslege (online stellen, das soll noch heute Nacht geshehen ), d.h. wenn ich jetzt in /usr/src/... reinclone (nach erstellen eines Repositories) werden modifzierte Dateien ueberschrieben bzw. wird Baum ergaenzt um Verzeichnis netmpls mit inhalt. Damit ich all das kompiliere muss ich ja den Baum aus /usr/src/sys/ verwenden... Wird bei Git definiert, dass nur Dateien Commitet werden (push,...) die im Repositiry sich befinden (obwohl ich momentan den Baum aus /usr/src/sys/.. verwende) oder wird dann der komplette Baum (versehentlich, was ich definitiv vermeiden will) hochgeladen (push)??? Ich weis, das ist eine etwas bekloppte Frage, aber ich stelle diese, da ich sehr wenig Erfahrungen mit Git habe.
 
Ich empfehle dir dringenst, dir die einschlägigen git tutorials zu Gemüte zu führen, damit du generell mit git umgehen kannst, sonst bringt das alles nichts. git push überträgt den Inhalt deines lokalen repos zu einem entfernten repo, einchecken macht ein git add *dateien* gefolgt von git commit.
Wenn du deine lokalen Änderungen veröffentlichst wird das gesamte git repo veröffentlicht. Du kannst aber auch die einzelnen Unterverzeichnisse als git submodules anlegen, die du dann unabhängig vom Eltern-repo irgendwo veröffentlichen kannst.
 
Ich glaube, es geht darum, ob Mergen mit git partiell auf dem Dateibaum geht. Also sollen nur ausgewählte Dateien unter Versionskontrolle gestellt werden.

So etwas geht nur mit manuellem Aufwand (meine ich, mag mich irren). Die meisten Leute würden die komplette Source-Base ins Git-Repo stellen. Das hat auch mehrere Gründe warum man es so machen sollte. Der initiale Aufwand beim Clonen des Git-Repos ist zwar größer, aber Du hast wenigstens die Garantie, dass stets richtig gemergt wird.

Und Mergen an sich ist schon eine schwierige Geschichte. Ich rate Dir schon mal, dass Du Dich mit Git auseinandersetzt. Dafür braucht man (meiner Ansicht nach) mehrere Monate als aktiver Entwickler. Bis zum Datenverlust ist sonst alles drin, wenn man das Werkzeug falsch benutzt. Git kann schon einige Sachen automagisch, aber die Unerfahrenheit und grobe Falschnutzung kann es nicht wegzaubern.
 
Danke fuer die schnellen Antworten. Lese gareadeeben http://git-scm.com/book/en/Getting-Started, die Komplexitaet von Git erschlaegt einen :).

Die komplette Basis?!? Das ist viel... da im Grunde genommen die Entwicklung "nur" 10 bis 15 Dateien umfasst. Hui... da muss ich kreativ werden, um die Entwicklung des Stacks von gesamter Basis zu entkoppeln. Dann muss ich wohl mal den McGyver wecken, der in mir steckt... wenn ichs geschafft habe werde ich entsprechende Info hier kommunizieren. Cheers.

Edit: Nun, jetzt weis ich genau wo nach ich recherchieren muss, werde zunaechst die bzgl. Entwicklung verwendeten Komponenten und Dateien isolieren und mir mal nanobsd anschauen bzw. nanobsd basierende git Repos analysieren.
 
Zuletzt bearbeitet von einem Moderator:
Mach doch einfach mal ein github account, clone das FreeBSD repo darein. Dann check deinen Clone aus, füge deine änderungen in den checkout ein, guck was so alles neu ist und mache eine "git add" auf die gewünschten Dateien, commit und push.

EDIT: najaa... eigentlich erstmal einen Branch machen mit "git branch my-awesome-mpls" und "git checkout my-awesome-mpls" vor dem einfügen von änderungen.

Da gibt es bei git keine magie im vergleich zu SVN o.Ä.

Natürlich sollte vermieden werden das Repo auf / zu erstellen. Die Pfade im Repo sind natürlich relativ.
 
das.chaos schrieb:
Die komplette Basis?!? Das ist viel... da im Grunde genommen die Entwicklung "nur" 10 bis 15 Dateien umfasst.
Zum Vergrößern anklicken....

Du wirst dankbar sein, wenn Du Deine Patches auf den aktuellen Baum einfach per "git rebase" draufspielen kannst, ohne dass Du krämpfe bekommst.

Oder nimm doch einfach den kleinsten Teilbaum. Oder splitte in kleinere Teilbäume. Die Weitergabe von Patches wird allerdings damit etwas verkompliziert, weil andere Leute sonst Deine Patches einfach in den Hauptbaum mit einem Remote-Zweig einbinden würden, aber so müssten sie alles manuell einspielen und Deinen nichtvorhandenen Remote-Zweig selbst führen (mit all den Nachteilen, wie abweichende Checksummen etc).

das.chaos schrieb:
Hui... da muss ich kreativ werden, um die Entwicklung des Stacks von gesamter Basis zu entkoppeln.
Zum Vergrößern anklicken....

Hä? Was muss man da entkoppeln? Da ist fast gar nichts zu tun, wenn man weiß was man tut.

das.chaos schrieb:
Edit: Nun, jetzt weis ich genau wo nach ich recherchieren muss, werde zunaechst die bzgl. Entwicklung verwendeten Komponenten und Dateien isolieren und mir mal nanobsd anschauen bzw. nanobsd basierende git Repos analysieren.
Zum Vergrößern anklicken....

Ja mach das. Lernen durch Abgucken klappt wunderbar.
 
Rotfl, stimmt... Repo clonen und eigenen Code reinbauen... ist die einfachste Loesung, ist mir geradeeben aufgefallen (nachdem ich Handbuch Ueberflogen habe). Manchmal denke ich etwas zu kompliziert (Wald und Baeume und so). GitHub Account ist erstellt, werde im Laufe der Nacht den Krempel uploaden und hier bzw. im Wiki Artikel verlinken... yeah :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben