.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.


  • Mod

    @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.

    @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.



  • @SeppJ sagte in .gitattributes:

    @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.



  • Vllt. hilft dir die Antwort in Files without extensions 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. 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
    


  • @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.



  • @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.



  • @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?



  • @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.



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



  • @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?



  • @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.



  • @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?



  • @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?



  • 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.



  • @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.



  • @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.



  • @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.



  • @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.



  • @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 😉


Anmelden zum Antworten