.gitattributes

Tyrdal

@hustbaer sagte in .gitattributes:

Also ich persönlich finde das automatische Konvertieren von Line-Endings grässlich. Ich drehe das grundsätzlich ab. Komplett.

@SeppJ

Oder meinst du, das ausgecheckte Script unter Windows soll auch nur lf haben? Während alles andere cr+lf behält? Falls ja: Warum? Unter Windows würde ein Script doch auch cr+lf erwarten.

Ein Grund wäre wenn man z.B. WSL verwendet. Oder ne VM verwendet wo man die Working-Copy rein mountet. Den Checkout macht man dann mit Windows, greift dann aber mit Linux auf die Files zu. Und Linux will halt einfach LF in den Shell-Scripts.

Das wäre ja ein Fall dafür, es auf input/false zu setzen, weil man effektiv unter non-Windows arbeitet.

Aber doch nicht für alles. Die anderen Datein sollen auf auto bleiben, weil auch unter Windows genutzt.

@Tyrdal sagte in .gitattributes:

Nö, der Shebang gibt doch den Interpreter an. Was gibts da zu raten?

Jedes Shellscript fängt mit Shebang an? Nein. Eine Datei darf nie mit Shebang losgehen, wenn sie kein Shellscript ist? Auch Nein. Außerdem ist "Shellscript-Sein" nach wie vor keine Eigenschaft der Datei, sondern des Inhalts.

Und der Inhalt definiert den Type. Ist aber auch wurscht wenn du deine unübliche Meinung vertrittst. man file sagt jedenfalls, dass ein file type ermittelt wird. Letztlich hilft mir das aber nicht weiter.

Th69

Vllt. hilft dir die Antwort in Files without extensions in .gitattributes?

Tyrdal

Ich hab jetzt einfach mit find, file etc den angeblich nichtexistenten file type ermittelt und die Namen der Shellskripte in die .gitattributes umgeleitet. Wenn eins dazu kommt muss man es halt händisch nachtragen.

fd -t f | xargs file --mime-type |rg shellscript|sed "s/^\.\///;s/:.*$/ text eol=lf/" >> .gitattributes

wob

@Tyrdal sagte in .gitattributes:

Ich hab jetzt einfach mit find, file etc den angeblich nichtexistenten file type ermittelt und die Namen der Shellskripte in die .gitattributes umgeleitet.

Streich das "angeblich"!

Mach doch mal eine Datei namens "xxx" mit dem Inhalt:

#include <stdio.h>
int main() { using x = int; puts("42\n"); }

Das ist offenbar C++. Wenn du file befragst, kommt "C source" raus. Woran sollte file jetzt auch erkennen, dass es C++ ist? File versucht so gut wie möglich zu raten, was du für eine Datei hast.

Tyrdal

@wob sagte in .gitattributes:

@Tyrdal sagte in .gitattributes:

Ich hab jetzt einfach mit find, file etc den angeblich nichtexistenten file type ermittelt und die Namen der Shellskripte in die .gitattributes umgeleitet.

Streich das "angeblich"!

Mach doch mal eine Datei namens "xxx" mit dem Inhalt:
#include <stdio.h>
int main() { using x = int; puts("42\n"); }
Das ist offenbar C++. Wenn du file befragst, kommt "C source" raus. Woran sollte file jetzt auch erkennen, dass es C++ ist? File versucht so gut wie möglich zu raten, was du für eine Datei hast.

Woran machst du denn fest, dass es ein C++ file ist? Am Inhalt kann man das nicht erkennen. Das Beispiel ist ein wenig sehr konstruiert.

wob

@Tyrdal sagte in .gitattributes:

Woran machst du denn fest, dass es ein C++ file ist? Am Inhalt kann man das nicht erkennen

"using" gibt es in C nicht. Es könnte auf eine "Textdatei" sein, die zufällig von C++ kompiliert werden kann. Oder eben C mit Fehlern. Das kann file nicht wissen. Das ist genau der Punkt. Du behauptest, file würde das irgendwie wissen können. Kann es nicht. Genau wie es ein shell-Script sein könnte. Eines mit sehr vielen Fehlern.

Das Beispiel ist ein wenig sehr konstruiert.

Es ging um die Frage, dass git sicher erkennen soll, ob es sich um ein Shellscript handelt. Ist zum Beispiel eine Datei, wo jemand mit #!/usr/binbash in die erste Zeile geschrieben hat, ein Shellscript? Musst du dazu nicht den Inhalt angucken und wissen, was es sein soll?

Tyrdal

@wob sagte in .gitattributes:

@Tyrdal sagte in .gitattributes:

Woran machst du denn fest, dass es ein C++ file ist? Am Inhalt kann man das nicht erkennen

"using" gibt es in C nicht.

Oh, das hatte ich übersehen.

Es könnte auf eine "Textdatei" sein, die zufällig von C++ kompiliert werden kann.

C++ Quellcode ist üblicherweise Text.

Das Beispiel ist ein wenig sehr konstruiert.

Es ging um die Frage, dass git sicher erkennen soll, ob es sich um ein Shellscript handelt.

Und das zu ermitteln ginge prinzipell. Meine Skripte haben das üblich shebang.

Tyrdal

Mal ne Frage, wenn es keinen Dateityp gibt, warum hat dann jeder Fileexplorer eine Spalte dafür?

wob

@Tyrdal sagte in .gitattributes:

Und das geht. Meine Skripte haben das üblich shebang.

DEINE Scipte mögen das haben. Es gibt aber vielleicht auch scripte, diese Zeile nicht haben. Der Nutzer ruft sie mit bash scriptauf.

Mal ne Frage, wenn es keinen Dateityp gibt, warum hat dann jeder Fileexplorer eine Spalte dafür?

Und was wird da angezeigt, wenn du die Datei umbenennst? Oder den Inhalt änderst? Geht das teilweise vielleicht nur über die Dateiendung?! Wird dir vielleicht auch mal "Image" angezeigt, wenn es eine in "klickmich.gif" umbenannte ausführbare Datei ist?

Tyrdal

@wob sagte in .gitattributes:

@Tyrdal sagte in .gitattributes:

Und das geht. Meine Skripte haben das üblich shebang.

DEINE Scipte mögen das haben. Es gibt aber vielleicht auch scripte, diese Zeile nicht haben. Der Nutzer ruft sie mit bash scriptauf.

Ja und? Es geht mir nur um meine Skripte.

Mal ne Frage, wenn es keinen Dateityp gibt, warum hat dann jeder Fileexplorer eine Spalte dafür?

Und was wird da angezeigt, wenn du die Datei umbenennst? Oder den Inhalt änderst? Geht das teilweise vielleicht nur über die Dateiendung?! Wird dir vielleicht auch mal "Image" angezeigt, wenn es eine in "klickmich.gif" umbenannte ausführbare Datei ist?

Ist doch egal. Es gibt sowas wie einen Type. Ob der nun durch die Endung oder was auch immer gekennzeichnet wird ist doch unerheblich.

wob

@Tyrdal sagte in .gitattributes:

Ist doch egal. Es gibt sowas wie einen Type. Ob der nun durch die Endung oder was auch immer gekennzeichnet wird ist doch unerheblich.

Du schriebst oben, damit fing es an...

Ich hab da nämlich ein Shellscript ohne Dateiendung,

Ok, also nochmal: was macht ein Shellscript denn aus? Die Dateiendung ist es schon mal nicht. Was zeigt denn dein Explorer bei deinem Shellscript an?

Tyrdal

@wob sagte in .gitattributes:

Ok, also nochmal: was macht ein Shellscript denn aus? Die Dateiendung ist es schon mal nicht. Was zeigt denn dein Explorer bei deinem Shellscript an?

Was macht es aus? Shell Befehle da drinnen.
Der zeigt ein kleines Terminal-Icon.

Worauf willst du hinaus?

wob

Nenn dein Scruipt mal script.exe, script.jpg usw. Der einzige Punkt ist, dass das Ergebnis nicht allgemeingültig zuverlässig ermittelt werden kann. Und es auch nicht im Dateisystem gespeichert sein muss. Wie SeppJ sagte.

Tyrdal

@wob sagte in .gitattributes:

Nenn dein Scruipt mal script.exe, script.jpg usw. Der einzige Punkt ist, dass das Ergebnis nicht allgemeingültig zuverlässig ermittelt werden kann. Und es auch nicht im Dateisystem gespeichert sein muss. Wie SeppJ sagte.

Das bedeutet doch aber nicht, dass es keinen Typ hat.
Wenn ich dem Skkript die Endung exe verpasse ermittelt file, dass es ein bash script ist, bei jpg genauso.

wob

@Tyrdal sagte in .gitattributes:

Das bedeutet doch aber nicht, dass es keinen Typ hat.

Es geht nur darum, dass der Typ nicht gespeichert ist. Der Typ ist derjenige, wie du die Datei interpretierst.

Wenn ich dem Skkript die Endung exe verpasse ermittelt file, dass es ein bash script ist, bei jpg genauso.

File rät ja anhand des Inhalts, aber auch dein Explorer?

Und: neulich lief mir auf twitter eine gif-Datei über den Weg, die gleichzeitig den Dateityp "Doom save game" (oder war es irgendeine Doom-Leveldatei, auch egal) hat. Welches davon richtig ist, musst du dann entscheiden.

Tyrdal

@wob sagte in .gitattributes:

@Tyrdal sagte in .gitattributes:

Das bedeutet doch aber nicht, dass es keinen Typ hat.

Es geht nur darum, dass der Typ nicht gespeichert ist. Der Typ ist derjenige, wie du die Datei interpretierst.

Also gibt es einen Typ, sag ich doch.

Wenn ich dem Skkript die Endung exe verpasse ermittelt file, dass es ein bash script ist, bei jpg genauso.

File rät ja anhand des Inhalts, aber auch dein Explorer?

Raten find ich etwas zu gewagt. Es gibt da öfter mal magic numbers, bestimmte Strukturen etc., die das doch recht zuverlässig machen. Ja, bei C vs C++ können sich mal Fehler einschleichen.
Was mein Explorer intern macht weiß ich nicht.

hustbaer

@Tyrdal sagte in .gitattributes:

Ist doch egal. Es gibt sowas wie einen Type. Ob der nun durch die Endung oder was auch immer gekennzeichnet wird ist doch unerheblich.

Es gibt Dateiformate - die auch oft als Dateitypen bezeichnet werden. Und es gibt Dateien. Und File-Extensions. Und Bytewürste. Das bestreitet alles keiner.

Der strittige Punkt ist ob das Dateiformat ein Attribut der Datei ist. Und das ist es halt einfach nicht. An der File-Extension kann man es nicht exakt festmachen, da viele Dateien keine Extension haben -- und da kann dann alles mögliche drin sein (Executable, Skripte, Text, Source Code, ...). Und dann sind manche Extensions sind auch nicht eindeutig. z.B. .bin, .db, .log oder auch .tmp - da kann auch alles mögliche drin sein.

Und am Inhalt kann man es halt auch nicht festmachen. Das Beispiel mit C und C++ kam ja schon. Wobei das Problem noch viel grösser ist: viele C Source Files sind auch gültige C++ Source Files. Und alle sind Textfiles. Was ist jetzt "der" Dateityp? Und man kann es auch so anstellen dass ein File gleichzeitig als C Source funktioniert und als Shell-Script.

Oder sieh dir das .com Format an. Das hat keine Header sondern enthält einfach direkt den Code. Wenn das File ausreichend klein ist kann es leicht passieren dass es keine Nullbytes enthält, und dann geht es schnell als Textfile durch.

Uswusf.

Also nein, eine Datei "hat" nicht ein Dateiformat oder einen Dateityp. Sie kann natürlich die Bedingungen eines oder mehrerer Dateiformate erfüllen. Deswegen zu sagen sie "hat" diese Dateiformate wäre aber Quatsch.

hustbaer

@SeppJ sagte in .gitattributes:

Das wäre ja ein Fall dafür, es auf input/false zu setzen, weil man effektiv unter non-Windows arbeitet.

Ich hab' mich mit dem Zeug ehrlich gesagt zu wenig beschäftigt als dass ich verstünde was "auf input/false zu setzen" bedeutet/bewirkt

SeppJ

@hustbaer sagte in .gitattributes:

@SeppJ sagte in .gitattributes:

Das wäre ja ein Fall dafür, es auf input/false zu setzen, weil man effektiv unter non-Windows arbeitet.

Ich hab' mich mit dem Zeug ehrlich gesagt zu wenig beschäftigt als dass ich verstünde was "auf input/false zu setzen" bedeutet/bewirkt

"input" macht, dass alles lf ist, so wohl intern als auch in ausgecheckter Form. Quasi das Non-Windows-Gegenstück von "true" (True macht intern alles als lf, aber ausgecheckte Dateien werden zu cr+lf umgewandelt). "false" macht "Fass nix an, nimm intern wie extern alles genauso wie es ist!". Was ein realistischer Usecase für false sein soll, weiß ich auch nicht, es ist wahrscheinlich einfach nur da, falls jemand ganz spezielle Nöte hat. Und prinzipiell braucht man die anderen beiden nur wenn man auf gemischten Systemen arbeitet und könnte in einer reinen Monokultur auch false wählen. Würde ich aber als sehr kurzsichtig ansehen, denn wenn sich das dann jemals ändert, kommt man in Schwierigkeiten.

Wenn man also ein ausgechecktes Repo in einem Unixsystem mounted, wäre input die richtige Wahl, selbst wenn das eigentliche Hostsystem Windows ist. Denn effektiv nutzt man das Repo dann unter Unix. Jetzt könnte man sagen: Was ist, wenn ich gleichzeitig von verschiedenen Systemen aus auf die gleichen ausgecheckten Dateien zugreife? Worauf ich erwidern würde, dass man sowieso die Kontrolle über den Inhalt verloren hat, wenn man ein geteiltes Arbeitsverzeichnis hat, und man dann ganz andere, dringendere Probleme hat.

hustbaer

@SeppJ
Ich verwende privat * -text im .gitattributes für meine C# Projekte. AFAIK sollte damit alles abgedreht sein, also alles binär 1:1, überall, immer. Gebaut wird nur auf Windows, und ab und an wird mal ein Binärfile eingecheckt.

Das Repo in der Arbeit ist aufwendiger konfiguriert - verschiedene Einstellungen für verschiedene Extensions. Also Shell-Skripte sind überall LF, Windows Batch Files und Visual Studio Project Files überall CRLF usw. Source Code ist auf "native" Line Endings auschecken eingestellt (=im Repo LF). Könnte ich aber gut drauf verzichten, ich hatte nie Probleme mit C++ Source/Header Files mit LF Line Endings auf Windows.

Und ja, ich nutze den selben Checkout auf 2 Systemen Windows und Linux per WSL. Funktioniert super. Keine "anderen, dringenderen Probleme". Ich verwende halt einfach keine Tools die mir die Line Endings ändern.

Bevor das .gitattributes Files auf der Arbeit befüllt wurde hatten wir sogar mixed Line Endings bei den Source Files (im selben File!). War in Wirklichkeit auch kein Problem. Wurde eigentlich nur geändert weil sich jemand eingebildet hat dass das "nicht schön"/"pfui" ist.

ps: Die Umstellung ist auch relativ problemlos gegangen. Also auch da keine echten Schwierigkeiten. Bei einem Repo mit zigtausend Files, Sourcen in verschiedensten Sprachen, Shell-Skripten etc. und an die 100 Pull Requests die zum Zeitpunkt der Umstellung offen waren - die mussten halt rebased werden. Jetzt haben wir halt einen fetten "line endings" commit in der History. Aber nichtmal der ist ein Problem bei Sachen wie blame, da quasi alle Blame-Tools whitespace Änderungen ignorieren können.