Git bash(ing)

Marco13 · November 9, 2020, 7:21pm

Ich ärgere mich auch gerne über vermeintliche Details.

git checkout my-experimental-brach

Antwort:

error: pathspec 'my-experimental-brach' did not match any file(s) known to git

Warum nicht

There is no branch called 'my-experimental-brach'. Add the '-b' flag to create it.

?

Ein sehr spezifisches Detail. Natürlich ~„weiß man, was man eintippen muss“, als „professioneller Softwareentwickler“. Aber das ist nur ein winziges mini-Beispiel für das Symptom: Die Doku, Benutzung, und Fehlermeldungen von Git sind eine subtile Botschaft:

Timothy_Truckle · November 12, 2020, 7:18am

Hmmm…

Was ist an dieser Stelle denn mehr zu bedauern, Deine Legasthenie oder Deine Abneigung gegen die Tab-Taste?
;o)

bye
TT

Marco13 · November 12, 2020, 1:06pm

„Tab“ funktioniert unter Windows nicht (vielleicht mit PowerShell oder GitBash oder sonstwas, aber erstmal nicht). Und vertippen kan man sich immer mal.

Über weitere Absurditäten muss man wohl nicht reden. Als Teaser: Einfach mal ein Git Repo erstellen, da eine Datei namens example reinlegen, und einen Branch namens example erstellen. Preisfrage: Was macht git checkout example danach? Ich würde mich schämen.

Timothy_Truckle · November 12, 2020, 8:48pm

Korrekt, geht nur in der gitbash. Aber wenn man schon in windoes was auf der Kommandozeile machen mus, warum sollte man die nicht benutzen? Ich schreime lieber bash-Skipte als batch-scripte…

Sicher, was auch nicht böse gemeint, passte nur gerade…
Auf jeden Fall kann man git aber nicht anlasten, dass Du Dich vertippt hast.

Jedes Werkzeug hat halt so seine Restriktionen. Es gibt ja auch keinen Hammer, mit dem man sich nicht auf den Daumen hauen kann…
;o)

bye
TT

Tomate_Salat · November 12, 2020, 9:12pm

Wenn du mit der Konsole arbeitest, dann würde ich dir echt Powershell empfehlen. Ich find ConEmu und https://github.com/JanDeDobbeleer/oh-my-posh ganz nett.

Marco13 · November 13, 2020, 12:30am

Nochmal: Das war nur ein Beispiel für etwas, was bei Git eben auf allen Ebenen zu beobachten ist: Irgendein Fachidiot hat die Scheuklappen aufgesetzt und sich ein tool gebastelt das wie ein Puzzleteil in seine eingeschränkte Weltsicht passt, und was jetzt die ganze Welt benutzt, und die Fehlermeldungen sind der letzte Rotz.

Und um „Restriktionen“ geht es gar nicht: Dass er bei git checkout wrongname was von „pathspec“ faselt kann ein Fachidiot zwar damit „„rechtfertigen““, dass da ja sowohl Dateinamen als auch Branchnamen angegeben werden können (und man bei git checkout MeineDatie.txt eben nicht eine Fehlermeldung ausgeben könnte, in der was von einem „Branch“ gesagt wird - man wollte ja schließlich eine Datei auschecken!), aber das war ein subtiler Hinweis darauf, dass eben schon genau diese Funktion zu nicht auflösbaren Mehrdeutigkeiten führt, und man das gelinde gesagt als „nicht besonders gut durchdacht“ bezeichnen könnte.

Timothy_Truckle · November 13, 2020, 2:18pm

Also erst mal ist git nicht das einzige SCM, wenn es Dir nicht passt kannst Du ja ein anderes nutzen.
Zweitens ist es kostenlos und einem geschenkten Gaul schaut man nicht in’s maul.
Und drittens habe ich noch kein von Dir programmiertes SCM gesehen.

Was ich sagen will: meckern ist einfach.

Auf der anderen Seite: genau dafür ist dieser Thread ja da…
;o)

Mit anderen Worten: ich verstehe Deinen Standpunkt, teile ihn aber nicht.

bye
TT

Clayn · November 13, 2020, 3:29pm

Das ist immer so ein Totschlagargument: Dann machs doch besser.
Ist nur ziehmlich wertlos.

Timothy_Truckle · November 13, 2020, 4:18pm

Mag sein, das ist so eine Aussage wie diese:

aber auch, denn die schreit förmich „Dunning-Kruger“…

bye
TT

Marco13 · November 13, 2020, 11:19pm

Geschenkter Gaul … von mir programmiertes SCM… Dunning-Kruger… oh jeh … *kopfschüttel* darauf jetzt eingehen? … ah, nee.

Aber vielleicht hilft eine Analogie: Wenn ich mich jetzt bei dir zuhause vor’s Fenster stellen und Trompete spielen würde, dann wäre das ja kostenlose Musikunterhaltung für dich … aber du wärst da sicher nicht erfreut daraüber, und könntest du nach wenigen Sekunden mit absoluter Sicherheit sagen, dass ich nicht wirklich Trompete spielen kann, auch wenn du selbst es keinen Deut besser kannst.

Allgemein: Manchmal weiß man nicht, wie man etwas „besser“ machen könnte, aber erkennt trotzdem, wenn etwas schlecht ist. In diesem Fall geht es um 1. Inkonsistentes Verhalten und 2. Besch****ne Fehlermeldungen. Wenn du der irrigen Annahme bist, du könntest da (über „näh-näh-selber-doof“ hinaus, also auf sachlicher Ebene) widersprechen, kannst du das gerne versuchen.

Timothy_Truckle · November 14, 2020, 10:00am

Nee, das wäre Lärmbelästigung.
Die bessere Analogie wäre, wenn Du mir einen Stuhl schenkst, der sehr schick aussieht aber kippelt, wenn man sich schief drauf setzt.

Da gebe ich Dir ja recht.
Trotzdem ist die Einschätzung „nicht durchdacht“ schlicht anmaßend. Ohne genauere Analyse weißt Du eben nicht, ob das, was Dich stört, nicht doch das kleinere Übel ist gegen über einer alternativen Implementierung, bei der dieses eine Problem nicht in dieser Form auftreten würde, dafür aber andere.

Wie auch immer: Ich verstehe den Frust über das aktuelle Problem, stimme euch aber nicht zu.

bye
TT

Landei · November 14, 2020, 10:05am

Ich habe lange Subversion benutzt, und habe lange gebraucht, um mit git zurechtzukommen. Ohne grafische Oberflächen, wo man „sehen“ konnte, was passiert, wäre es noch frustrierender gewesen. Dann hatte ich mal ein Projekt mit Mercurial. Von der Arbeitsweise her ähnlich wie git, aber die Benennung mehr wie Subversion. Allein dadurch war die Lernkurve nur halb so hoch. Mercurial hat nun auch seine Schwächen und Probleme, aber viele Bedienungsprobleme bei git müssten einfach nicht sein. Inzwischen ist git gut mit IDEs integriert, und ich weiß, wie es zu bedienen ist, aber auf der Kommandozeile benutze ich es immer noch ungern.

anon65336368 · November 14, 2020, 10:39am

Die git command line ist wirklich nicht gut. Als Alternative gäbe es noch https://gitless.com/, aber das funktioniert leider nicht unter Windows.

Marco13 · November 14, 2020, 2:26pm

Ein „guter“ Stuhl kippelt nicht, egal, wie schief man sich draufsetzt. Und die Zweideutigkeit, auf die bei Git - git-checkout Documentation eingegangen wird, wäre schon durch git checkoutPath und git checkoutFile aufgehoben.

Das Feststellen dieser Schwächen (als „nicht durchdacht“) als „anmaßend“ zu bezeichnen, leuchtet mir nicht ein, deswegen nochmal die konkreten Fragen an dich:

Ist die Zweideutigkeit bei checkout „gut“, Ja oder Nein?
Glaubst du, dass diese Zweideutigkeit unvermeidbar ist?
Ist die Fehlermeldung „gut“, Ja oder Nein?
Glaubst du, dass man dort keine „bessere“ Fehlermeldung ausgeben könnte?

Und wenn du diese Fragen (wie ich) mit „nein“ beantworten würdest, dann müßtest du mir erklären, warum es „anmaßend“ ist, festzustellen, dass das eben so ist…

Tomate_Salat · November 14, 2020, 4:10pm

Hab das Thema mal abgespalten.

Also ich mag git. Aber auf der Kommandozeile tu ich mir auch nicht mehr an als das:

git clone xyz
git push
git pull
git add .
git commit -m "I've forgotten what I've done"

In seltenen Fällen fällen vllt auch mal ein

git checkout my/broken/file.whatever

aber auch nur dann, wenn ich mich dran erinnere, dass das so geht. Das mache ich aber auch nur dann, wenn ich gerade die IDE geschlossen hab und zu faul zum öffnen bin. Für alles andere brauche ich aber die IDE.

Timothy_Truckle · November 14, 2020, 7:09pm

Ich sprach nicht von einem „guten“, sondern einem „schönen“ Stuhl. Denn genau das passt zu deinem Problem: Niemand stört es außer Dir, weil Du halt schräg drauf sitzt. Der Rest der Welt findet den Stuhl einfach schick und sitzt gerade.

Weil, wenn es so wie hier von Dir vorgeschlagen implementiert wäre, man dann auch noch ein checkoutTag und checkoutHash bräuchte. Und dann kämen so Leute wie Du daher, die sich darüber aufregten, warum man für das Auschecken vier unterschiedliche Kommandos bräuchte, die eigentlich alle das selbe tun. Das gäbe es ja bei anderen SCMs auch nicht.

Und allein die Tatsache, dass checkout unterschiedliche Objekte auschecken kann, man also entsprechenden code scheiben musste, um das möglich zu machen, zeigt, dass der Vorwurf „nicht durchdacht“ nicht zutrifft.

Und dass Du Deine Sicht auf dieses Feature als die einzig Richtige betrachtest, und den Leuten, die fieses Feature designed haben, die Kompetenz abstreitest, ist halt das klassische Dunning-Kruger-Symptom.

Aber ich denke, ich klinke mich hier mal aus der Diskussion aus, bevor das in eine unschöne Richtung abgleitet.

bye
TT

Marco13 · November 15, 2020, 12:39am

Und ich habe ganz bewußt von einem „guten“ Stuhl geredet, und nicht von einem „schönen“. Ob er schön ist, oder nicht, ist zu subjektiv. Ob er wackelt oder nicht ist eines von mehreren möglichen vergleichsweise objektiven Kriterien, um das „gut“ zu beurteilen.

Ein anderer Analogieversuch: Stell’ dir vor, in deinem Auto gäbe es einen Knopf der mit „Licht“ beschriftet ist. Wenn es dunkel ist, bewirkt der, dass das Licht angeht. Wenn man bremst, bewirkt er, dass das Bremslicht angeht. Wenn man das Lenkrad eingeschlagen ist, bewirkt er, dass der Blinker angeht (In der Bedienungsanleitung würde natürlich nicht „Blinker“ stehen, sondern „Fahrtrichtungsanzeiger“. Den Begriff verwendet niemand, und die meisten verstehen ihn nicht, aber es ist ein schöner, technisch korrekter Begriff). Wenn es neblig ist, geht mit dem Knopt die Nebelschlussleuchte an. Wenn die Tür offen ist, betätigt der Knopf die Innenbeleuchtung. Nach einer Weile würden sich die Leute daran gewöhnen, und es würde irgendwie funktionieren.

Wenn dann jemand vorschlagen würde: „Hey, vielleicht sollte es für unterschiedliche Funktionen auch unterschiedliche Knöpfe geben?“, dann könnte auch jemand sagen: „Eeeey, willst du das Armaturenbrett mit Knöpfen vollkleistern, obwohl alle einfach nur Licht anmachen?! Bist wohl zu dumm, den Knopf richtig zu bedienen. Voll Dunning-Kruger du, bau’ doch erstmal selbst ein Auto!!!111“. Ziemlich unsachlich, überzogen, und in keiner Hinsicht sinnvoll oder konstruktiv, aber … derjenige würde das natürlich sagen, weil er es für angebracht hielte, also … OK.

Es ist ein gewaltiger Unterschied, ob man eine Datei oder einen Branch auscheckt. Das Händewedeln um die „disambiguation“ herum im oben verlinkten Abschnitt der Anleitung ist schon ein starkes Indiz dafür, dass diese Mehrdeutigkeit zu Problemen führen kann.

Du hast dich um die Beantwortung der Fragen herumgemogelt:

Ist die Mehrdeutigkeit gut?
Ist die Fehlermeldung gut?

Die Antwort ist vielleicht zu offensichtlich, als dass du findest, sie sei es wert, gegeben zu werden, aber sie ist wichtger Baustein meiner Verteidigung gegen deine albernen Vorwürfe. Ich habe gesagt, dass der Befehl mehrdeutig ist (und das ist wahr, und das ist nicht gut), und ich habe gesagt, dass die Fehlermeldung sche!ße ist (und da habe ich bisher noch keinen Widerspruch gehört).

Das einzige sinnvoll aus letzterem (und aus dem Wort „Fachidiot“) ableitbare „Abstreiten von Kompetenz“ kann ich auch gerne nochmal so artikulieren: Git ist nicht auf einfache Verständlichkeit und Benutzerfreundlichkeit ausgelegt (speziell im Hinblick auf Doku und Fehlermeldungen, aber auch technisch, z.B. im Hinblick auf Sicherheit oder Konsistenz der Kommandozeilenbefehle - dazu hatte ich bisher aber noch nichts gesagt).

Vielleicht hast du die Aussagen auch „breiter“ interpretiert, als sie waren. Ich habe nicht gesagt, dass ~„git komplett und von vorne bis hinten nur sche!ße ist“. Vielleich täuscht das aber auch: Ich beobachte leider zu oft, dass meine Philosophie „Ich sage, was ich meine, und ich meine, was ich sage“ von so wenigen Menschen geteilt oder auch nur verstanden zu werden scheint, und finde das bedauerlich (oder eben… frustrierend … das könnte jetzt wieder in den anderen Thread )

mrBrown · November 15, 2020, 4:52pm

Hm, interessante Diskussion.
Die einen möchten gesonderte Befehle zum auschecken von Branches und Dateien und die anderen fänden solche Befehlen völlig überflüssig.
Und git steht ganz unbeteiligt in der Ecke und freut sich, dass es seit über einem Jahr switch und restore gibt.

Marco13 · November 16, 2020, 2:02am

Hah! Ein Glitzersternchen für mrBrown
_{(Und … im Hinblick auf die Zweideutigkeit fühle ich mich dadurch bestätigt, und meine Aussage zur Fehlermeldung stimmt auch immernoch )}