[offtopic] Github

[RalfFriedl]

Dann flashen wir doch mal wieder die alte Firmware auf den Server.

 

[olistudent]

https://github.com/olistudent/Freetz
https://github.com/Freetz/Freetz

Hm, ist natürlich genau so kompliziert wie erwartet. Nix funktioniert auf anhieb. Der initial commit dauerte Stunden...

Wie gehts jetzt weiter? Die commits müssen in das repository gepusht werden? Noch was?

Gruß
Oliver

 

[hermann72pb]

@Oliver: Nachdem du den halben Tag damit vermutlich verbracht hast, kannst du uns bitte aufklären, ob das alte gute Trac-System mit SVN noch tut? Angenommen, dieses git würde funktionieren, wie würden dann Trac- und Git-Sachen miteinander synchronisiert? Kommen wir da nicht durcheinander? Und warum liegt es jetzt nicht bei euch auf dem Server, sondern weiß der Geier wo? Ist es wirklich der Sinn der Sache? Irgendwie stehe ich nicht auf verteilte Systeme...

MfG

 

[olistudent]

Das ist doch erstmal nur ein Versuch. Ich hatte vor das git als Spiegel das svn zu nutzen. Und zwar ohne den Aufwand selbst ein qit Server aufzusetzen. Am bisherigen System ändert sich nichts. Der Fehler von er13 kam nur daher, dass ich in den git sync in den trac post commit hook aufgenommen hatte und das repo noch nicht da war...

Gruß
Oliver

 

[cuma]

Funktioniert das auch schon vom git ins Trac?

 

[olistudent]

Nein. Da bin ich mir auch nicht sicher, ob wir das anfangen sollen. Mal sehen, vielleicht wenn das mit Eclipse funktioniert...

@cuma
Ich häng die Patches von fda77 mal hier an. Betrifft rrdstats und external, also deine Baustellen.

@svoop
Angeblich kann man die Pull Requests als Patch Dateien aus github laden. Weißt du wie das funktioniert?

Gruß
Oliver

 

[cuma]

Das sind meine GIT-Tests

@all: Wie kann man einzelne Commits als Pull-Request stellen? Geht das überhaupt?

 

[svoop]

Angeblich kann man die Pull Requests als Patch Dateien aus github laden. Weißt du wie das funktioniert?

Das habe ich noch nie gebraucht, aber hier ist es beschrieben:
http://beust.com/weblog/2010/09/15/a-quick-guide-to-pull-requests/

Wie kann man einzelne Commits als Pull-Request stellen? Geht das überhaupt?

Ich glaube nicht, dass das geht. Technisch wäre es ohnehin höchstens möglich, die ersten n Commits isoliert als Pull Request abzusetzen, da ansonsten die Referenz fehlt. Wofür würdest du dieses Feature brauchen?

Eigentlich ist die Arbeitsweise eher, für jeden Task (z.B. netatalk portieren) einen eigenen Branch zu machen und wenn fertig alle Commits in diesem Branch als Pull Request abzusetzen. Die einzelnen Commits kannst du dabei jederzeit bearbeiten, also z.B. einen Commit herausnehmen, Commits bündeln etc:
http://www.silverwareconsulting.com/index.cfm/2010/6/6/Using-Git-Rebase-to-Squash-Commits

Wenn ich schon bei Tipps bin, hier ein paar Resourcen zu Git, jeweils mehr oder weniger aktuell:

Bücher und Guides (kostenlos):
* Git Community Book (mit Screencasts)
* Git Magic
* Pro Git Book
* Everyday Git Guide (20 Befehle für den Alltag)
* Getting to Grips with Git

Und dann gibt es noch einen Screencast, der die grundsätzlich erklärt, wie Git intern aufgebaut ist und funktioniert und mir persönlich enorm geholfen hat, den Unterschied zwischen SVN und Git zu begreifen. Ist leider nicht gratis, wenn trotzdem jemand sich dafür interessiert, kann ich den Link heraussuchen.

 

[cuma]

Danke, dafür brauch ich wohl noch etwas Einarbeitsungszeit. Hatte mir das so vorgestellt dass ich in meinem Fork irgendwelche Dinge reinmache wie ich sie persönlich nutze, und nur davon welche pushe die ich sinvoll erachte, zB nicht https://github.com/fda77/Freetz/commit/2acac38febe0f9b8f6e467e1f1f03b987f5b653f

 

[svoop]

Danke, dafür brauch ich wohl noch etwas Einarbeitsungszeit. Hatte mir das so vorgestellt dass ich in meinem Fork irgendwelche Dinge reinmache wie ich sie persönlich nutze, und nur davon welche pushe die ich sinvoll erachte, zB nicht https://github.com/fda77/Freetz/commit/2acac38febe0f9b8f6e467e1f1f03b987f5b653f

In diesem Fall gucke dir Branches und Stashes genauer an. Bevor du eine "persönliche Schiene" einschlägst, erstellst du einfach einen Branch dafür. (Du kannst den Branch auch noch machen, wenn es schon Änderungen gibt, die noch nicht committed sind - falls es dir erst bei der Arbeit einfällt.)

Der Vorteil: Du kannst später jederzeit diese Branches rebasen, d.h. die zugrunde liegende Ursprungsversion auf den neusten Stand bringen und allfällige Kollisionen auflösen. Deine Branches altern also mit dem Rest des Codes.

Für ganz kleine Sachen würde ich indes eher Stashes (ungefähr dasselbe wie Clipboards von Changesets) empfehlen. Diese sind ausschliesslich lokal, können also nicht gepushed werden. Und sie gelten egal wo, d.h. sie sind nicht an den aktiven Branch gekoppelt. Du kannst also einen Stash auf Branch A erstellen und auf Branch B dann anwenden - wobei Kollisionen wieder aufgelöst werden können. Stashes sind also eher mit "mit Git gespeicherte Patches" zu vergleichen.

Insgesamt hast du gerade in diesem Bereich mehr Möglichkeiten als mit SVN. Ein guter Client ist dabei sehr hilfreich - vor allem, um das Commit Log und die Forks/Merges zu visualisieren. Ich kann allerdings nur mit Tips für Mac helfen, da gibt es z.B. GitX, GitBox und jede Menge Plugins für Textmate, Eclipse, Netbeans etc. Ähnlich viel wenn nicht noch mehr existiert für Linux und Windows.

 

[Silent-Tears]

Ich will ja kein Spielverderber sein, aber git-Kurse haben wohl ebensowenig wie svn-Kurse was hier zu suchen, oder?
Btw: Wer braucht git für das bisschen Zeugs und Leute, was wir da haben?

 

[svoop]

Ich will ja kein Spielverderber sein, aber git-Kurse haben wohl ebensowenig wie svn-Kurse was hier zu suchen, oder?

Ich würde ja den Titel um "[off topic]" ergänzen, aber das geht (nicht) mehr.

Btw: Wer braucht git für das bisschen Zeugs und Leute, was wir da haben?

Vielleicht wären es dann ja mehr Leute, die mitmachen können.

 

[Silent-Tears]

Ah, und weils offtopic ist, schieben wir das nun ins offtopic-board bitte?

Und das andere: Mal ehrlich, wer nicht 3 svn kommandos lernen kann oder ein svn plugin im eclipse nutzen, der sollte noch einmal die Prioritäten ordnen.

 

[svoop]

Und das andere: Mal ehrlich, wer nicht 3 svn kommandos lernen kann oder ein svn plugin im eclipse nutzen, der sollte noch einmal die Prioritäten ordnen.

Ich sehe nicht, was dieser Kommentar mit allen vorangehenden zu tun haben soll. Okay, du magst Git nicht, soviel habe ich verstanden.

 

[Silent-Tears]

Git ist mir an sich egal, ich sehe nur keine Notwendigkeit, alles auf den Koopf zu stellen, weil es so funktioniert und nicht unbedingt nur weil einer da nicht mit umgehen und lernen will, alles auf einmal schlecht ist. Von daher...

 

[olistudent]

Ich hab hier nirgendwo gelesen, dass jemand alles schlecht findet was wir gerade machen. Und da wir ja offen für Vorschläge sind und nicht gleich alles neue schlecht reden kann man auch auf Vorschläge von Nutzern eingehen. Ob wir in Zukunft irgendwann mal mit Git arbeiten wird sich zeigen.

Die Linearität (Einfachheit) von Subversion-Repositories hat (gerade in kleineren Gruppen) auch ihre Vorteile.

Wenn ich mir anschaue was man alles machen muss um so einen Pull Request auf Github in das Repository zu pushen, dann ist der Aufwand dem jetzigen ähnlich. (Patch anwenden und einchecken)
Nützlich ist das ganze doch wirklich nur, wenn die "Hauptarbeit" von der Community gemacht wird und die Devs die Commits nur noch überprüfen?

Gruß
Oliver

 

[RalfFriedl]

Git hat durchaus einige interessante Eigenschaften.

Allerdings überzeugt mich das Argument nicht, daß es zu mühsam sei, "svn diff" aufzurufen, um einen Patch zu erstellen.

 

[svoop]

Git hat durchaus einige interessante Eigenschaften. Allerdings überzeugt mich das Argument nicht, daß es zu mühsam sei, "svn diff" aufzurufen, um einen Patch zu erstellen.

An sich ist fork/merge à la Github das Pendant zu Patches mit jedem anderen VCS. (Wobei Subversion dank "git diff" benutzerfreundlicher als andere ist.)

Der Vorteil ist allerdings, dass die Patches nicht wild in der Gegend sprich. einem Tracker herumhängen, sondern eingebettet sind in die Versionierung. Es ist also immer klar, auf welcher Basis ein Git Branch aufsetzt und man kann ihn grundsätzlich immer à jour bringen.

Wenn ich z.B. an netatalk monatelang nichts machen kann, dann bin ich nach einem einfachen Rebase wieder up to speed. Umgekehrt ist mein Branch auch dann noch brauchbar, wenn sich inzwischen dessen Basis weiterentwickelt hat.

Gut möglich, dass diese Vorteile im Vergleich zum Aufwand für einen Wechsel nicht rechnen - das herauszufinden habe ich als Nicht-Dev ja überhaupt gefragt. Aber da das nicht-lineare Modell gerade bei solchen Projekten an sich auftrumpfen kann, ist es schon einen Gedankenaustausch wert. Ich komme danach auch nicht wieder mit dem Thema.