Jammer-Thread

[Chromanoid]

Naja, Paypal Gebühren fallen doch immer nur für den Verkäufer/Empfänger an. Paypal muss für viele Benutzer sorgen, damit Verkäufer ihre API anbinden, am besten exklusiv. Von den Verkäufern lebt dann Paypal. Endverbraucher sind Transaktionsgenerierer, die eigentlichen Kunden sind die Verkäufer. Klar, kann man die Endverbraucher auch als wichtige Partner von Paypal interpretieren, aber solange man damit durchkommt und der Netzwerkeffekt reicht, macht es doch wenig Sinn über das Notwendige hinaus etwas für die Benutzer zu tun, solange die Verkäufer nicht leiden und die Plattform nicht an Nutzern einbüßt. Facebook muß auch für genug Nutzer sorgen, damit die Werbetreibenden eine Zielgruppe haben, aber am Ende sind die Benutzer das Produkt. Diejenigen, die für einen Dienst zahlen, sind Kunden.

[Jonathan]

Natürlich gebe ich auch großen Konzernen aus Bequemlichkeit meine Daten. Wer nicht?

Das ist doch nicht Bequemlichkeit. Wenn ich wirklich wert darauf lege, dass meine privaten Daten nicht zu werbezwecken analysiert werden, dann bin ich doch vom gesellschaftlichen Leben komplett ausgeschlossen. Man kann sich an einigen Stellen vielleicht entscheiden mehr oder weniger preis zu geben. Aber letztendlich kannst du ja nichtmal von deinem hippen Data-Safe Email-Betreiber an Menschen mit gmail-Adressen schreiben oder irgendjemanden deinen Namen und deine Telefonnummer erzählen der WhatsApp auf seinem Handy installiert hat. Das sind jetzt Extrembeispiele, aber zumindest bei mir war es dann halt so, dass ich irgendwann zwangsweise einen Facebook-Account brauchte, weil ich sonst nicht mehr mitbekommen hätte, wo sich meine Freunde treffen und sozial isoliert gewesen wäre. Das kann man doch nicht Bequemlichkeit nennen...

[Jonathan]

lol, gerade gefunden:

"But what happens when a business with the same impact on your life as the government appears to go bad? Recently, the payment processing behemoth PayPal crossed a line by proposing an alarming rule: It planned to begin assuming the role of “thought police” by modifying its terms of service to allow it to collect a $2,500 fine and freeze a person’s funds if they spread “misinformation.” "

https://thehill.com/opinion/technology/ ... oing-back/
https://fortune.com/2022/10/10/paypal-u ... confusion/
https://www.reuters.com/business/financ ... 022-10-10/

[Alexander Kornrumpf]

Natürlich gebe ich auch großen Konzernen aus Bequemlichkeit meine Daten. Wer nicht?

Das ist doch nicht Bequemlichkeit. Wenn ich wirklich wert darauf lege, dass meine privaten Daten nicht zu werbezwecken analysiert werden, dann bin ich doch vom gesellschaftlichen Leben komplett ausgeschlossen. Man kann sich an einigen Stellen vielleicht entscheiden mehr oder weniger preis zu geben. Aber letztendlich kannst du ja nichtmal von deinem hippen Data-Safe Email-Betreiber an Menschen mit gmail-Adressen schreiben oder irgendjemanden deinen Namen und deine Telefonnummer erzählen der WhatsApp auf seinem Handy installiert hat. Das sind jetzt Extrembeispiele, aber zumindest bei mir war es dann halt so, dass ich irgendwann zwangsweise einen Facebook-Account brauchte, weil ich sonst nicht mehr mitbekommen hätte, wo sich meine Freunde treffen und sozial isoliert gewesen wäre. Das kann man doch nicht Bequemlichkeit nennen...

Alles schön und gut. Ich will auch nicht groß diskutieren, da ich nicht besonders in das Thema investiert bin. Was ich sagen will: ich habe, nur mal so zum Beispiel, einen facebook account. Ich "brauche" den in dem Sinne nicht, aber ich bin nicht in der Position jemanden zu verurteilen, der gerne einen facebook account hätte. Ich verstehe auch warum man gerne einen facebook account würde haben wollen, du hattest selbst einen möglichen Grund genannt.

Bei Paypal sehe ich aber den Anwendungsfall nicht. Darum ging es mir. Ich bin einfach neugierig was einen hindert dann halt ohne paypal zu leben, wenn es so schlimm ist wie hier beschrieben. Nicht aus Häme oder Kritik, sondern weil ich wirklich noch nie paypal gebraucht habe.

[Jonathan]

Bei Paypal sehe ich aber den Anwendungsfall nicht. Darum ging es mir. Ich bin einfach neugierig was einen hindert dann halt ohne paypal zu leben, wenn es so schlimm ist wie hier beschrieben. Nicht aus Häme oder Kritik, sondern weil ich wirklich noch nie paypal gebraucht habe.

Hab gerade in einem Online-Shop ein Handy bestellt. Man konnte nicht per Überweisung oder Bankeinzug bezahlen, nur per Kreditkarte oder PayPal (und noch so eine dritte Option, die aber auch super sketchy aussah). Ich hab per Kreditkarte bezahlt, das hat aber 2 mal mit einer Fehlermeldung abgebrochen. Dann hab ich PayPal benutzt, nicht weil ich die mag, sondern weil ich da eh schon einen Account hatte, die eh schon meine Nummer haben, alles andere mal wieder nicht funktioniert hat und ich keinen Bock mehr hatte...

Aber ok. Ist kein gutes Argument, ich hätte auch nächste Woche offline im Geschäft einkaufen können. Gut, hätte ich nicht, weil ich gerade unterwegs bin, aber theoretisch halt schon. Ich meine, das ist ja ein wenig so als würde man sich beschweren, dass Uber ein totaler Saftladen ist, aber man behauptet zur Benutzung gezwungen zu werden, weil normale Taxis zu teuer sind. Aber naja, unbefriedigend ist das trotzdem...

[Alexander Kornrumpf]

Hab gerade in einem Online-Shop ein Handy bestellt. Man konnte nicht per Überweisung oder Bankeinzug bezahlen, nur per Kreditkarte oder PayPal (und noch so eine dritte Option, die aber auch super sketchy aussah). Ich hab per Kreditkarte bezahlt, das hat aber 2 mal mit einer Fehlermeldung abgebrochen.

Ein Anruf bei der Telefonnummer die auf der Kreditkarte steht klärt normalerweise ob es an der Kreditkarte oder an dem Shop liegt. Der Kundenservice der Kreditkartenanbieter ist nach meiner Erfahrung auch deutlich besser als der der meisten Shops (oder von Paypal for that matter). Wenn es an der Kreditkarte liegt klären die das direkt mit dir. Wenn es am Shop liegt, wovon ich ausgehe, will der wohl dein Geld nicht haben. Ich würde da dann nichts kaufen, selbst wenn Paypal ansonsten das beste Unternehmen der Welt wäre.

Aber ok. Ist kein gutes Argument, ich hätte auch nächste Woche offline im Geschäft einkaufen können.

Ich kaufe online fast nur bei Amazon. Also nicht Amazon Marketplace, Amazon Amazon. Ich hatte mit denen noch nie Probleme, wenn doch was sein sollte rufe ich dort an und es lässt sich klären. Ich schätze dass ich da im Laufe der letzten 20 Jahre oder so einen inzwischen hohen 5-stelligen Betrag gelassen habe und Amazon weiß das und behandelt mich entsprechend. Der Fachbegriff lautet "iteriertes Gefangenendilemma" denke ich.

Zu den Skills die Amazon hat gehört es z. B. dass sie in der Lage sind Kreditkartenzahlung zu implementieren *zwinkersmiley*.

Ich meine, das ist ja ein wenig so als würde man sich beschweren, dass Uber ein totaler Saftladen ist, aber man behauptet zur Benutzung gezwungen zu werden, weil normale Taxis zu teuer sind. Aber naja, unbefriedigend ist das trotzdem...

Ist ja oft so, dass es von an sich beschissenen Sachen eine nicht-beschissene Variante gibt, die dann halt teuer ist. Die erste Klasse im ICE ist z. B. weitestgehend erträglich, die normale Klasse not so much.

[Krishty]

*seufz*

Mir ist wieder was in die Hände gespielt worden. Aber leider werde ich erstmal nicht drüber schreiben, denn es ist voll von so Dingen wie

Code: Alles auswählen

** Copyright (c) 1995, ██████████████████████
** All Rights Reserved.
**
** This is UNPUBLISHED PROPRIETARY SOURCE CODE of ██████████████████████;
** the contents of this file may not be disclosed to third parties, copied or
** duplicated in any form, in whole or in part, without the prior written
** permission of ██████████████████████

Code: Alles auswählen

//               █████████████████ PROPRIETARY INFORMATION
//  This software is supplied under the terms of a license agreement or
//  nondisclosure agreement with █████████████████ and may not be copied
//  or disclosed except in accordance with the terms of that agreement.
//        Copyright (c) 1995 █████████████████. All Rights Reserved.

Code: Alles auswählen

 * Copyright (c) ███████████████████ 1993, 1994
 * Version 1.1
 *
 * All rights reserved.
 *
 * This file contains private, unpublished information and may not be
 * copied in part or in whole without express permission of
 * ███████████████████

Code: Alles auswählen

 * ███████ Project - PROPRIETARY INFORMATION
 * Copyright 1994-95, ████████████ All Rights Reserved

… die meisten Firmen gibt es noch, und sie sind recht klagefreudig. Mal gucken, wie ich das für die Allgemeinheit der Retro-Computing-Freunde verpacken kann.

[Krishty]

Leute: “Git ist zu kompliziert. Branches und Stashes … wer soll das lernen? Sowas brauche ich eh nicht!”

Ebenfalls Leute:

Code: Alles auswählen

#ifdef NOT_________COMPILED_BY_KRISHTY
  #define ASSET_PATH "c:\\foo\\bar\\"
#elif defined COMPILED_BY_TINA
  #define ASSET_PATH "c:\\foo.pc\\bar\\"
#elif defined COMPILED_BY_BEN
  #define ASSET_PATH "c:\\lol\\foo.win\\bar\\"
#elif defined COMPILED_BY_BENHOME
  #define ASSET_PATH "f:\\lol\\foo.win\\bar\\"
#elif defined COMPILED_BY_BOB
  #define ASSET_PATH "D:\\foo.win\\bar\\"
#elif defined COMPILED_BY_ALICE
  #define ASSET_PATH "c:\\projects\\foo.win\\bar\\"
  #define ASSET_PATH2 "e:\\projects\\foo.win\\bar\\"
#endif

„Ben daheim“ ist ja mein Favorit.

[Lord Delvin]

Oo

[Chromanoid]

m(
wobei ich kein git fan bin...
https://mobile.twitter.com/markrussinov ... 5249052672

[Krishty]

m(
wobei ich kein git fan bin...
https://mobile.twitter.com/markrussinov ... 5249052672

Eher:

[Chromanoid]

Bah, das kann man ja nirgends posten, wenn man kein git-Fan ist... :D

[Jonathan]

Wer git über die Kommandozeile nutzt ist an seinem eigenen Elend selbst schuld. Ist so.

Ich benutze seit Jahren tortoiseGit, und das macht auch wenn man damit einmal einen komplizierten Merge gemacht hat und das Prinzip verstanden hat kriegt man das auch nach 2 Jahren Abwesenheit wieder auf Anhieb hin und zwar ohne 20 Befehle nachzugucken. Weil man in der GUI halt sieht was man macht und die Befehle die man braucht einfach auswählen kann. Der ganz überwiegende Teil von Git-Bedienfehlern die ich gesehen habe kommt von Menschen die meinen alles per Kommandozeile machen zu müssen aber das halt einfach nicht können und dann geht es halt schief. Tja, selbst schuld.

Das zweite Problem ist, dass Versionsverwaltung einfach inhärent kompliziert ist. Keine Frage, git ist super kompliziert und man muss sich darein wochenlang einarbeiten aber man verwendet halt ein mächtiges Tool um ein kompliziertes Problem zu lösen.

Das traurige ist halt, dass die meisten git nicht können. Wir benutzen hier standardmäßig Overleaf (ein schreckliches Tool) um Paper kollaborativ zu schreiben. Overleaf ist halt rotzig, weil es dich nicht nur zwingt einen beschissenen Online-Texteditor zu nutzen der 1/3 der Features hat die ich brauche, es löst das Problem der Versionsverwaltung halt auch einfach nicht sondern umgeht es durch Edit-Anarchie. Aber auf gewisse Weise ist es halt trotzdem besser als git mit Menschen die git nicht können zu benutzen. Ich kenne ehrlich gesagt keinen einzigen Informatik-Professor der einen merge in git hinbekommen würde. Da wird dann gerne mal "solve conflict using MINE" angeklickt und commited und gut ist.

[Chromanoid]

Naja, der git Jargon ist halt schon ein absoluter fuckup. Bei fetch, pull, checkout und clone handelt es sich doch fast um Synonyme. Und wenn sachkundige "Casual User" im Grunde standardmäßig zerstörerische Fehler machen, spricht das für sich.

[Krishty]

Bei aller Kritik: Was machen Casual User denn Destruktives? Die Standard-Befehle sind nie destruktiv und fragen im Zweifel grundsätzlich nach.

Man kann sich ja auch so ziemlich *alles* mit reflog rekonstruieren. Das ist natürlich nicht offensichtlich für Casual Users, aber auch nicht schwärzere Magie als wirklich destruktive Aktionen wie Rebase des Repositories.

Ich fucke in git sehr viel ab, aber eigentlich auch nur, wenn ich nicht den offensichtlichen Casual-Befehlen folge sondern was ganz Spezielles will.

[Chromanoid]

Wenn der git Guru kommen muß, damit es wieder heile ist, ist das für mich destruktiv. Das gab's in meinem Umfeld jetzt schon ab und zu. Das Problem ist ja, dass man Konflikte mit verteilter Versionsverwaltung viel schneller verschleppt. Mir geht das bei Git wie es mir mit Word geht, das muss doch besser gehen... Ich muss mit Word glücklicherweise nicht mehr arbeiten, aber mit git schon. Git ist natürlicherweise mächtiger als Subversion und ich benutze es lieber, aber besser fühlt es sich nicht an. Ich nutze momentan eine Mischung aus gitlens für vsc und cli. TortoiseGit liegt mir irgendwie nicht so.

[Alexander Kornrumpf]

Das Problem ist ja, dass man Konflikte mit verteilter Versionsverwaltung viel schneller verschleppt.

Kannst du das vielleicht noch ein bisschen weiter entpacken?

Konflikte:
Geht es um Konflikte im git oder im code? Was ich damit meine: dass zwei Leute gleichzeitig inkompatibele changes im Code machen können ist ja gerade der Sinn von git und in dem Sinne kein Problem. Wenn zwei Leute gleichzeitig inkompatible changes am git repository an sich (also den metadaten) machen ist das wahrscheinlich ein Problem, aber wie oft, und warum, tut man das?

Ich sehe auch in beiden Fällen nicht wie das Problem sinnvoll in einer Versionsverwaltung gelöst werden soll. Code Changes: Im allgemeinen Fall gibt es nicht immer eine Vereinigung, die die Versionsverhaltung zumindest hypothetisch konstruieren könnte. Meta Data Changes: Was man hier eigentlich fordern würde ist eine Meta Versionsverwaltung und was machst du wenn _deren_ Metadaten konfligieren? Das ist eine unendliche Rekursion.

mit verteilter Versionsverwaltung:
Naja, git ist auf dem Papier eine verteilte Versionsverwaltung. In Realität wird es ja doch wohl (in Unternehmen?) meistens so benutzt, dass es irgendwo ein zentrales Origin gibt, was die source of truth ist und wo ein github-Äquivalent als Frontend davor ist, no?

viel schneller verschleppt:
Interessanterweise ist die Grundannahme des CI teils von CI/CD (was auch immer man sonst davon hält) ja, dass dieses Problem so schwer zu lösen ist, dass es _leichter_ ist das Problem zu lösen wie man gefahrlos immer nach master mergen kann. Der ganze Sinn der Übung ist es ja gerade, die Zeitspanne, die etwas "verschleppt" werden kann, auf 20 Minuten oder so runterzubekommen. Ich sage nicht dass das das Allheilmittel ist, aber viele, auch schlaue, Leute scheinen zumindest implizit nicht sehr viel Hoffnung zu haben, dass das in absehbarer Zeit auf Ebene der Versionsverwwaltung gelöst wird.

[Chromanoid]

Mit Konflikten meine ich alle möglichen Probleme, die dadurch entstehen, dass mehrere Leute am gleichen Repository arbeiten. Sei es ein gut gemeintes Rebase, das allen den lokalen Stand versaut, oder ein versehentliches "solve conflict using MINE", wenn man eigentlich nur den aktuellen Stand pullen will, vorher aber committen muss bzw. eigentlich stashen o.Ä. Da gibt es ja zig Möglichkeiten gerade als Einsteiger Fehler zu machen.

Bei einer zentralen Versionsverwaltung ergibt sich automatisch eine leichter zu überblickende Historie und Konflikte sind ebenfalls leichter nachzuvollziehen. Eine verteilte Verwaltung insbesondere Git ist hier komplizierter, weil es mehr abbilden kann und Git sich technisch sehr entblößt zeigt.

Mit Verschleppen meine ich, dass Probleme leichter unter gehen, weil man technisch und organisatorisch dazu aufgerufen ist isolierter zu arbeiten (z.B. https://www.thoughtworks.com/radar/tech ... ll-request) und dadurch viele Probleme erst wirklich sichtbar werden, wenn man mental schon wo anders ist.

Es gibt da ja viele verschiedene Artikel zu, z.B. https://gregoryszorc.com/blog/2017/12/1 ... -fix-them/. Ich schreibe da ehrlich gesagt aus meiner Intuition heraus. Um noch mal auf Word zurück zu kommen. Das hat im Grunde das umgekehrte Problem wie Git. Word ermöglicht dem User zu vieles, ohne dass dieser versteht, was im Dokument technisch passiert. Das führt zu schlechten Dokumenten bzw. schlechten Gefühlen, wenn irgendwo plötzlich leere Seiten auftauchen etc. Git hingegen zwingt den Benutzer zu nahe an der technischen Umsetzung zu arbeiten, so dass viel zu viel von Git verstanden werden muss, bevor damit schön gearbeitet werden kann. Ein guter Mittelweg sollte das Ziel sein.

Nachtrag: Ich meine hier ausdrücklich die UX (also die Gefühle, die man vor, bei und nach der Benutzung von Git in einem übergeordneten Zusammenhang hat).

[Alexander Kornrumpf]

Mit Konflikten meine ich alle möglichen Probleme, die dadurch entstehen, dass mehrere Leute am gleichen Repository arbeiten. Sei es ein gut gemeintes Rebase, das allen den lokalen Stand versaut

Ich weiß nicht ob es schlau ist das öffentlich zuzugeben, aber ich kenne mich nicht gut genug mit git aus um überhaupt das Problem zu verstehen. Mein Bauchgefühl sagt dass es hier um irgendwelche "da sieht die History schöner aus" Aesthetik oder so geht - wie Leute, die nach solchen Kriterien gut gemeinte Entscheidungen treffen, Code schreiben will man normalerweise auch nicht sehen. Der Fall dass man seine eigenen lokalen changes auf den dann aktuellen Stand des origin rebased hat mir zumindest noch nie Probleme bereitet und ich sehe auch nicht wie er das könnte.

, oder ein versehentliches "solve conflict using MINE", wenn man eigentlich nur den aktuellen Stand pullen will, vorher aber committen muss bzw. eigentlich stashen o.Ä. Da gibt es ja zig Möglichkeiten gerade als Einsteiger Fehler zu machen.

Sollte man vielleicht gerade als Einsteiger ein Tool für sowas verwenden? Natürlich kannst du theoretisch argumentieren, dass git die High-Level Operationen, von Haus aus mitbringen sollte, aber irgendwas irgendwas Unix-Philosophie.

[Krishty]

Wenn der git Guru kommen muß, damit es wieder heile ist, ist das für mich destruktiv. Das gab's in meinem Umfeld jetzt schon ab und zu.

Mit Konflikten meine ich alle möglichen Probleme, die dadurch entstehen, dass mehrere Leute am gleichen Repository arbeiten. Sei es ein gut gemeintes Rebase, das allen den lokalen Stand versaut, oder ein versehentliches "solve conflict using MINE", wenn man eigentlich nur den aktuellen Stand pullen will, vorher aber committen muss bzw. eigentlich stashen o.Ä. Da gibt es ja zig Möglichkeiten gerade als Einsteiger Fehler zu machen.

Oh stimmt – man kann recht einfach anderen das Leben schwer machen. Das ist in der Tat ein Problem; ich bekomme es auch bisweilen zu hören … weil ich privat viel rebase, mache ich schon fast instinktiv git push -f. Ich muss mich auf der Arbeit jedes Mal beherrschen und habe Angst, dass es destruktiv endet, wenn ich mal nicht genauestens aufpasse.

Trotz allem würde ich ein Rebase auf gepushtem Stand nicht zu den Standard-Befehlen zählen, und auch nicht push -f.

[Chromanoid]

Ich muss mich auf der Arbeit jedes Mal beherrschen und habe Angst, dass es destruktiv endet, wenn ich mal nicht genauestens aufpasse.

Und das von Dir...

"da sieht die History schöner aus" Aesthetik

Das hat ja auch damit was zu tun, dass jemand anderes den Code reviewen bzw. lesen muss. Klar, wenn man immer sauber arbeitet, kann man das vielleicht sauber lösen. Aber wo nichts dreckig wird, wird auch nicht gearbeitet... Und da will man dann eben doch mal rebasen oder was auch immer, was man nicht remote tun sollte, wenn andere daran arbeiten. Das wird einem dann erst hinterher klar... Es gibt sicher auch Probleme mit anderen Versionsverwaltungsprogrammen und Git ist besonders exponiert, aber wenn man nach "detached head" googlet, ist das schon ziemlich gruselig. Klar kann man sich daran gewöhnen, aber es kommen ja auch ständig neue Menschen dazu, die das dann bitte auch tun. Das hat immer mit den Menschen zu tun, aber wenn ich sowas lese https://www.reddit.com/r/ExperiencedDev ... n_a_weird/ hilft git sicher nicht besonders bei den menschlichen Problemen.

[Krishty]

Ich muss mich auf der Arbeit jedes Mal beherrschen und habe Angst, dass es destruktiv endet, wenn ich mal nicht genauestens aufpasse.

Und das von Dir...

Aber eben auch nur, weil ich öfter rebase, als sich andere Leute am Sack kratzen. Eher aus OCD denn aus Notwendigkeit, und empfehlen würde ich es niemandem. TFS habe ich mit ähnlichen Extravaganzen auch schon kaputtgekriegt :D

[Alexander Kornrumpf]

"da sieht die History schöner aus" Aesthetik

Das hat ja auch damit was zu tun, dass jemand anderes den Code reviewen bzw. lesen muss. [...] Und da will man dann eben doch mal rebasen oder was auch immer [...]

Aber eben auch nur, weil ich öfter rebase, als sich andere Leute am Sack kratzen. Eher aus OCD denn aus Notwendigkeit, und empfehlen würde ich es niemandem.

Sorry aber ich raffs nicht. Also alles was ich im Folgenden sage hat natürlich keine Gültigkeit für CI, aber wenn man CI macht hat man das Problem sowieso nicht, weil man ständig kleine Teile merged?!

Wie gesagt, es ist vielleicht nicht schlau das öffentlich zuzugeben, aber meine commit history sieht natürlich genau so aus wie man es von jemandem der das nicht rafft erwarten würde. Ich halte das für ein Feature. Man _will_ doch nachvollziehen können wie der Gedankengang von demjenigen war, der den change gemacht hat, und in welchen Schritten es erfolgt ist. Ich bin aus demselben Grund auch gegen squash commits. Es sollte doch klar sein (?), dass ein Change in 10 schritten leichter nachzuvollziehen ist, als wenn man ihn in einem Schritt präsentiert bekommt. Man fasst ja gegebenenfalls dieselbe Stelle im Code zweimal an, da kann der Weg von Ausgangspunkt und Endergebnis schonmal sehr weit sein. Ich vergleiche das mal mit einer Herleitung in Mathe.

Noch nie habe ich im Code Review (das ja dann in erster Näherung die Commits de fakto für die Anzeige doch wieder squasht, also zumindest mein Tool tut das - wie gesagt, ist doch ok, dass git barebones ist, gibt ja tools die darüber ansetzen) gedacht "Mann, ich wünsche der Kollege hätte rebased".

Wenn ich mich bei der "eigentlichen" Arbeit (also nicht im Review) durch 5 oder 6 Versionen rückwärts klicken muss (tools, again) um zu sehen wie ein Change passiert ist, freue ich mich aus o. g. Grund. Ich habe dann auch 5 mal soviele Commit Messages (=Dokumentation).

Wie gesagt, ich rebase meine Changes nach dem Pull auf den dann aktuellen Stand von Origin bevor ich Pushe. (Ich hoffe ich habe jetzt nicht die Lingo versemmelt, real macht das natürlich Intellij und nicht ich). Wenn es dabei Konflikte gibt merge ich klassisch. Ich glaube nicht dass dabei was kaputt gehen kann, zumindest ist es mir noch nicht passiert. Ich meine in git kaputtgehen. Natürlich kann ich beim Merge den Code kaputtmachen, das kann ich immer.

Ich bin gar nicht so sehr pro git, damit wir uns nicht missverstehen. Ich bin da komplett unemotional. Ich nutze vielleicht 10% von dem was es kann und der Teil scheint zu funktionieren. Ich würde gerne verstehen wofür ihr die anderen 90% braucht, die anscheinend ständig kaputtgehen.

[Krishty]

Sorry aber ich raffs nicht. Also alles was ich im Folgenden sage hat natürlich keine Gültigkeit für CI, aber wenn man CI macht hat man das Problem sowieso nicht, weil man ständig kleine Teile merged?!

Wie gesagt, es ist vielleicht nicht schlau das öffentlich zuzugeben, aber meine commit history sieht natürlich genau so aus wie man es von jemandem der das nicht rafft erwarten würde. Ich halte das für ein Feature. Man _will_ doch nachvollziehen können wie der Gedankengang von demjenigen war, der den change gemacht hat, und in welchen Schritten es erfolgt ist. Ich bin aus demselben Grund auch gegen squash commits. Es sollte doch klar sein (?), dass ein Change in 10 schritten leichter nachzuvollziehen ist, als wenn man ihn in einem Schritt präsentiert bekommt. Man fasst ja gegebenenfalls dieselbe Stelle im Code zweimal an, da kann der Weg von Ausgangspunkt und Endergebnis schonmal sehr weit sein. Ich vergleiche das mal mit einer Herleitung in Mathe.

Schließe mich weitgehend an.

Hauptgrund für Rebase: Drei Tage nach dem Push feststellen, dass Visual Studio die neu hinzugefügte Datei wieder als ANSI gespeichert hat denn als UTF-8. Oder dass ich irgendwo Einrückung vermasselt habe oder die Komnetare voler Typsos snid. Im normalen Workflow macht so ein Kleinkram locker ein Drittel der Commits aus. Da wäge ich ab und sage: Das birgt kein großes Risiko einer Regression; ich rebase und merge das mit dem Original-Commit. Aber dann wird git push -f halt zur Gewohnheit / motorisches Gedächtnis.

Für Sqashing bin ich, wenn man mehrere Releases pflegen musst. Auf dem Feature Branch kann die Historie ruhig lauten

• Neue Funktion hinzufügen
• Ergänze vergessenen Kommentar
• Repariere Unit-Tests
• Korrigiere Typo in Kommentar
• Repariere Debug-Build auf 32-Bit-Maschinen

aber für die Leute upstream und in den Release-Branches ist das doch nur Noise, der ihnen das Cherry-Picking erschwert. Meistens.

CI bedeutet doch übrigens auch, immer einen funktionierenden Build zu haben, oder? Ich möchte in den Release-Branches keine Commits haben, die den Build kaputtmachen. Dann lieber Rebase mit Korrektur als Fixup. Dann funktioniert auch git bisect.

Im Feature-Branch, wie gesagt, ist der Noise egal und die Nachvollziehbarkeit wichtiger.

[Alexander Kornrumpf]

Hauptgrund für Rebase: Drei Tage nach dem Push feststellen, dass Visual Studio die neu hinzugefügte Datei wieder als ANSI gespeichert hat denn als UTF-8. Oder dass ich irgendwo Einrückung vermasselt habe oder die Komnetare voler Typsos snid. Im normalen Workflow macht so ein Kleinkram locker ein Drittel der Commits aus.

Ich habe ganz gute Erfahrung damit gemacht, Kleinkram, der mir auffällt, dann halt in dem ansonsten unrelated commit zu fixen, in dem es aufgefallen ist. Ich sehe warum das je nach sonstigen Gegebenheiten ein Problem sein kann, ich verargumentiere das als "den Code etwas besser hinterlassen, als man ihn vorgefunden hat". Wenn man einen separaten Commit machen will, halte ich den Fakt, dass der dann out-of-order ist, für verschmerzbar, aber man darf dann natürlich nicht squashen, da schließt sich der Kreis.

aber für die Leute upstream und in den Release-Branches ist das doch nur Noise, der ihnen das Cherry-Picking erschwert. Meistens.

Also upstream von mir ist aktuell niemand mehr und manchmal muss ich auch bugs in Produktionscode fixen, dann hätte ich gerne die History trotzdem. Aber klar, ist situativ, ich verstehe schon das Argument.

CI bedeutet doch übrigens auch, immer einen funktionierenden Build zu haben, oder? Ich möchte in den Release-Branches keine Commits haben, die den Build kaputtmachen. Dann lieber Rebase mit Korrektur als Fixup.

CI bedeutet für verschiedene Personen verschiedenes, aber ich denke die kanonische in Universe Antwort ist, dass du a) den Teil der Pipeline bis einschließlich Unit Tests sowieso ständig lokal laufen lässt und b) nach dem push in der Verantwortung bist, den zentralen Build zu beobachten und wenn er kaputt geht sofort zu fixen.

Das setzt natürlich voraus, dass die Pipeline angemessen schnell durchläuft, also wahrscheinlich kantet es C++ und zu einem gewissen Grad auch Java sofort raus.

[Lynxeye]

Jetzt muss ich als jemand, bei dem git eine zentrale Rolle bei der täglichen Arbeit spielt, auch mal meinen Senf dazu geben.

Hauptgrund für Rebase: Drei Tage nach dem Push feststellen, dass Visual Studio die neu hinzugefügte Datei wieder als ANSI gespeichert hat denn als UTF-8. Oder dass ich irgendwo Einrückung vermasselt habe oder die Komnetare voler Typsos snid. Im normalen Workflow macht so ein Kleinkram locker ein Drittel der Commits aus. Da wäge ich ab und sage: Das birgt kein großes Risiko einer Regression; ich rebase und merge das mit dem Original-Commit. Aber dann wird git push -f halt zur Gewohnheit / motorisches Gedächtnis.

Das ist halt bei Branchen auf denen auch andere Leute arbeiten eine Todsünde. Du läufst ja immer mit den Anderen um die Wette: wenn in deinem git pull/fetch/update, rebase, push ein Kollege neue Inhalte auf den geteilten Branch pusht, machst du ja Zwangsläufig etwas kaputt. Außerdem kannst du natürlich auch für andere Leute Konflikte generieren, die vorher nicht da waren. Das ist in der Zusammenarbeit immer unangenehm.

Wie gesagt, es ist vielleicht nicht schlau das öffentlich zuzugeben, aber meine commit history sieht natürlich genau so aus wie man es von jemandem der das nicht rafft erwarten würde. Ich halte das für ein Feature. Man _will_ doch nachvollziehen können wie der Gedankengang von demjenigen war, der den change gemacht hat, und in welchen Schritten es erfolgt ist. Ich bin aus demselben Grund auch gegen squash commits. Es sollte doch klar sein (?), dass ein Change in 10 schritten leichter nachzuvollziehen ist, als wenn man ihn in einem Schritt präsentiert bekommt. Man fasst ja gegebenenfalls dieselbe Stelle im Code zweimal an, da kann der Weg von Ausgangspunkt und Endergebnis schonmal sehr weit sein. Ich vergleiche das mal mit einer Herleitung in Mathe.

Noch nie habe ich im Code Review (das ja dann in erster Näherung die Commits de fakto für die Anzeige doch wieder squasht, also zumindest mein Tool tut das - wie gesagt, ist doch ok, dass git barebones ist, gibt ja tools die darüber ansetzen) gedacht "Mann, ich wünsche der Kollege hätte rebased".

Rebase heißt ja nicht zwangsläufig die gesamte Historie zu verschleiern indem man alles in einen Commit squasht. Rebase ist erst mal nur ein Werkzeug um die Historie zu ändern. Es kommt oft vor, dass ich während ich an einem Feature arbeite viele kleine Commits ansammle, mir nach Abschluss der Implementation aber denke, dass die Änderung anders aufgeteilt besser zu verstehen ist. In diesem Fall kann man mit rebase natürlich die Historie neu schreiben und für den Reviewer besser nachvollziehbar machen. Evtl. sogar noch in kleinere Commits aufteilen, um die einzelnen Änderungen besser voneinander zu trennen. Das hilft dem Reviewer, das hilft aber auch mir, wenn ich nach langer Entwicklungszeit ein Feature in den Hauptbranch integrieren will: natürlich mache ich dort dann ein rebase, um die vielleicht vorhandenen Konflikte zu lösen. Wenn die Historie dann aus kleinen, nachvollziehbaren Commits besteht fällt es mir auch leichter die Interaktion meiner Änderung mit dem upstream Änderungen zu beurteilen und den Konflikt sinnvoll zu lösen.

Vielleicht ist das auch der zentrale Punkt, den viele Nutzer zentraler Versionsverwaltung nicht sehen, der von vielen git Nutzern aber als essentiell angesehen wird: mittels Aufteilung in kleine Commits und rebase ist es möglich ein Feature über lange Zeit, im Fall des Linux kernels teilweise sogar über Jahre, in einem Fork/Branch zu entwickeln und Konflikte mit dem upstream inkrementell mittels rebase zu lösen und bin am Ende in der Lage das Ergebnis sauber in den upstream zu mergen. Das erfordert eine Umstellung der Herangehensweise: Konflikte sind in diesem Modell nicht zu vermeiden, also sehe ich sie als normaler Bestandteil meines Workflows an und strukturiere meine Commits und die Historie so, dass sie mir nicht weh tun.

[Alexander Kornrumpf]

Rebase heißt ja nicht zwangsläufig die gesamte Historie zu verschleiern indem man alles in einen Commit squasht. Rebase ist erst mal nur ein Werkzeug um die Historie zu ändern. Es kommt oft vor, dass ich während ich an einem Feature arbeite viele kleine Commits ansammle, mir nach Abschluss der Implementation aber denke, dass die Änderung anders aufgeteilt besser zu verstehen ist. In diesem Fall kann man mit rebase natürlich die Historie neu schreiben und für den Reviewer besser nachvollziehbar machen. Evtl. sogar noch in kleinere Commits aufteilen, um die einzelnen Änderungen besser voneinander zu trennen. Das hilft dem Reviewer, das hilft aber auch mir, wenn ich nach langer Entwicklungszeit ein Feature in den Hauptbranch integrieren will: natürlich mache ich dort dann ein rebase, um die vielleicht vorhandenen Konflikte zu lösen. Wenn die Historie dann aus kleinen, nachvollziehbaren Commits besteht fällt es mir auch leichter die Interaktion meiner Änderung mit dem upstream Änderungen zu beurteilen und den Konflikt sinnvoll zu lösen.

Vielleicht ist das auch der zentrale Punkt, den viele Nutzer zentraler Versionsverwaltung nicht sehen, der von vielen git Nutzern aber als essentiell angesehen wird: mittels Aufteilung in kleine Commits und rebase ist es möglich ein Feature über lange Zeit, im Fall des Linux kernels teilweise sogar über Jahre, in einem Fork/Branch zu entwickeln und Konflikte mit dem upstream inkrementell mittels rebase zu lösen und bin am Ende in der Lage das Ergebnis sauber in den upstream zu mergen.

Danke für die Erklärung. Ich denke in der Tat, das sagte ja auch schon Krishty, dass eine entscheidende Variable ist, ob es überhaupt ein Upstream gibt und ich sagte selbst oben ja schon, dass ich denke, dass insbesondere Unternehmen es nicht so benutzen, wie Linux Kernel Entwickler, sondern weitestgehend als wäre es eine zentrale Versionsverwaltung mit ein paar Extras.

Das erfordert eine Umstellung der Herangehensweise: Konflikte sind in diesem Modell nicht zu vermeiden, also sehe ich sie als normaler Bestandteil meines Workflows an und strukturiere meine Commits und die Historie so, dass sie mir nicht weh tun.

Ich finde es sehr bemerkenswert, wie das das genaue Anti-Modell zu CI ist. Ich denke wir müssen nicht diskutieren, welches von beiden "richtig" ist, aber es ist doch spannend, dass beide Extreme schlaue Vertreter finden. Das Pessimum liegt wahrscheinlich in der Mitte: Das berühmte schlechteste aus beiden Welten.

[Chromanoid]

Zu CI und Trunk Based Development (?). Je nach "Pattern for Managing Source Code Branches" leben Branches ja länger oder kürzer - also wenn es eben kein trunk-based development ist.

Boyscout-Rule-Kram finde ich schrecklich irgendwo anders unterzubringen. Das geht nur bei bestimmten Entwickler-Typen gut. "Pragmatischer" arbeitende Genossen bauen so gerne mal kleine Bugs ein, die dann bei der Review tierisch nerven, weil man sich nicht auf das eigentliche konzentrieren kann.

Wir machen "Post-Push"-Review mit einem Entwicklungs-Branch, der in eine Testumgebung deployt wird. Davon bin ich ziemlich überzeugt, zumindest innerhalb des Rahmens, den ich so kennenlernen durfte.

Ich glaube wie gesagt nicht, dass git an sich blöd ist, gefühlt ist es aber eher sowas:

[Krishty]

Hauptgrund für Rebase: Drei Tage nach dem Push feststellen, dass Visual Studio die neu hinzugefügte Datei wieder als ANSI gespeichert hat denn als UTF-8. Oder dass ich irgendwo Einrückung vermasselt habe oder die Komnetare voler Typsos snid. Im normalen Workflow macht so ein Kleinkram locker ein Drittel der Commits aus. Da wäge ich ab und sage: Das birgt kein großes Risiko einer Regression; ich rebase und merge das mit dem Original-Commit. Aber dann wird git push -f halt zur Gewohnheit / motorisches Gedächtnis.

Das ist halt bei Branchen auf denen auch andere Leute arbeiten eine Todsünde. Du läufst ja immer mit den Anderen um die Wette: wenn in deinem git pull/fetch/update, rebase, push ein Kollege neue Inhalte auf den geteilten Branch pusht, machst du ja Zwangsläufig etwas kaputt. Außerdem kannst du natürlich auch für andere Leute Konflikte generieren, die vorher nicht da waren. Das ist in der Zusammenarbeit immer unangenehm.

Inmitten der Arbeitszeit wäre das wahrscheinlich eine Todsünde, ja. Mache ich das Samstag vormittag, und pullen Montag früh alle mit --rebase (siehe Meme), macht das überhaupt keine Probleme. Eine der Stärken ist ja, dass ich die Historie verändern kann und die lokale Arbeit der anderen nimmt beim Pull diese Historie an, sofern sie nicht direkt mit ihren Änderungen kollidiert. Bei kleinen Teams spricht also IMHO nichts dagegen.

[Krishty]

Ein paar Revisions-Kommentare aus der prä-Git-Ära:

Code: Alles auswählen

*  Revision 1.35  1997/05/22 11:57:06  ██████
*  lots of files that haven't changed - but my hard drive got fucked

*  Revision 1.16  1997/02/03 14:47:09  ███████
*  I foolishly typed touch *.obj, I only cahnged █████.c/h and ██████.c/h

   Revision 1.8  1996/02/29 23:15:12  ████
   Reinstate correct stuff after cvs spawned a parallel divergent universe
   after a timeslip.

(CVS checkt gern Dateien ein, obwohl man sie nicht geändert hat. So kann eine minimale Änderung aussehen, als wäre die halbe Codebase refactored worden, und damit verhaut man anderen die Möglichkeit, zu mergen.)