GitHub Messages in der Liste

Tim Niemeyer tim.niemeyer at mastersword.de
Mi Nov 12 19:09:05 CET 2014


Hi


> * "GitHub has an amazing code review system called Pull Requests":
> Nutze Pull-Request um Änderungen zum Review zu stellen (keiner will
> mehr olle Patches per mail)
Das ist nach wie vor eine Geschmackssache. Bisher gibt es nur den
Vorteil, dass es für den Maintainer etwas komplizierter ist die Patches
anzuwenden. Aber zum diskutieren taugt mir persönlich ne ML bisher noch
besser.

Aber mal was anderes. Hast du mal Lust (wir machen das hier ja auch um
was zu lernen) mal Gerrit zu testen? http://gerrithub.io/

Ansonsten wäre es, nach wie vor, mMn noch sinnvoll ein paar mal den
Workflow über Patches durch zu gehen. Dadurch lernt man wirklich viel
besser wie Git wirklich funktioniert.

> * "Pull Requests preserve a record of the historical changes to your
> code": Nutze GitHub-Merge um Pull-Requests als ganzes in den master zu
> mergen. Der dadurch entstehende Merge-commit macht klar, dasss es sich
> hier um ein Patch-Set und nicht einzelne Patches handelt.
Ein Merge Commit entsteht nur, wenn es wirklich was zum mergen gibt. Ist
der Featurebranch sauber, wird immer ein FF gemacht. Das wird auch beim
Github nicht anders sein. Ich verstehe deine Intension, aber ich denke
das geht Prinzip bedingt nicht. Aber das können wir gern nochmal testen.

> * Bitte auch keine einzelnen Commits aus einem Pull-Request mergen es
> sei denn der Pull-Request wird danach tatsächlich verworfen und das
> ist mit dem Contributer so abgesprochen. Das schafft "Chaos" und mach
> dem Contributer das Leben unötig schwer.
Ich bin da bisher dran gegangen, wie man es mit Patches, die in
Patchsets gebündelt werden. Das ist in der Regel ein gängiger Weg. Wir
können gern davon abweichen, aber diese Regel könnte auch schnell im Weg
stehen, wenn man ein Entwickler sein Patchsatz nicht weiter verbessern
will und die eine Hälfte aber sehr gut ist.

> * Wenn du Anmerkungen zu einem speziellen Commit hast nenn diesen auch
> beim Namen (Hash). Commit-spezifiche Anmerkungen gehören als Kommentar
> zu dem Commit. Ganze Pull-Request nicht wegen einzelner Commits
> verteufeln!
Da dachte ich jetzt eigentlich, dass GitHub das für mich macht, wenn ich
direkt was an einen Commit schreibe. Reicht dir das nicht?

> * Auch "unschöne" Pull-Request (Patchsets) kann man als Ganzes
> inhaltlich reviewen und Rückmeldung geben. Mann muss sich in GitHub
> nicht von Patch zu patch hangeln.
Wenn man dafür Zeit hat, natürlich. Mache ich ja auch. Aber ich ging
davon aus, dass du das sauber machen kannst. Ich geh da eigentlich immer
individuell vor. Ich versuche niemanden zu verprellen.
Die Arbeitsweise von Patch zu Patch zu gehen halte ich weiterhin für gut
und wichtig. Immerhin sind darin ja die logischen Änderungen zusammen
geführt. Stell dir vor, wenn jemand ein Commit macht, wo in jeder Zeile
die Whitespaces repariert werden und im zweiten Commit dann eine andere
richtige und wichtige Änderung macht. Schaut man sich das ganze an,
sieht man die wichtige Änderung nicht mehr.

> * Es gibt noch viele Git Anfänger. Durch eine ganz oder garnicht
> Mentalität schließt man Anfänger und andersdenkende komplett aus und
> schadet dem ganzen Projekt. Toleranz!
Wie gesagt, ich hab dich nicht als Anfänger eingestuft. Ich kann das
gern ändern, aber dann solltest du bitte auch etwas mehr Zeit einplanen,
dass die Leute über deine Sachen drüber gucken. Du hast da die Tage doch
echt einiges an Druck gemacht. Es war einfach zu viel Druck. Wir machen
das alles ehrenamtlich, da kann es auch schon mal ein paar Tage dauern.
Insbesondere ich bin den ganzen Tag am Arbeiten, da schaffe ich nicht
jeden Abend deine Sachen anzugucken.

> * Pull-Request sollten nur vom Contributer selbst oder durch ein Merge
> geschlossen werden.
Ok, ich dachte wenn die Sache durch ist (und ich dachte du hättest mir
den Ball zugespielt), dann macht man das Ding zu und der Entwickler
bessert nach und macht ein neuen Request. Können wir gern anders machen.
Wollte dich nicht verärgern.

> * Wir entwickeln nicht der schönen Git-Historie wegen sondern wegen
> der Software. Im Zweifelsfall auch unschöne "Patch-Sets" mergen wenn
> der Code passt. Den Contributer auf Verbesserungen hinzuweisen schadet
> allerdings nicht.
Wir müssen aber auch eine Software machen, die auf Dauer wartbar und
nachvollziehbar ist. Dazu gehört eben auch eine saubere Historie.
Insbesondere, wenn du andere Menschen bittest ihre Zeit zu opfern, damit
die sich dein Kram angucken, gehört eine wirklich gute Vorbereitung
dazu. Stell dir vor ich geb dir ein Text zum Korrekturlesen und ich hab
das nicht mal selber quergelesen, und der ganze Text ist ergibt
eigentlich gar kein Sinn. Dann ärgerst du dich auch. Wir sollten also
bitte wirklich versuchen die Historie sauber zu halten.

Wie du siehst ist es nicht so einfach und jeder macht es doch irgendwie
ein wenig anders. Es gibt eben nicht den einen Ablauf. Deswegen hatte
ich vorgeschlagen mal in Ruhe darüber zu reden.

Tim
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 836 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20141112/1534b3eb/attachment-0002.sig>


Mehr Informationen über die Mailingliste franken-dev