.gitattributes

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

[wob]

@hustbaer sagte in .gitattributes:

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.

Tipp: Du kannst eine .git-blame-ignore-revs anlegen, in der du Commits einträgst, die nicht beim blame erscheinen sollen. Das habe ich z.B. in einem Python-Projekt für ein paar "black formatting" commits gemacht - das Projekt war alt und ohne automatische Formatierung gestartet. Ist allgemein sehr angenehm, weil du dann auch bei umformatierten Zeilen nicht mehr den Autor des Format-Commits siehst.

[hustbaer]

@wob sagte in .gitattributes:

.git-blame-ignore-revs

Danke. Haben wir auch. Hatte ich bloss schon wieger vergessen. Wobei ich vorher schon kein Problem damit hatte, weil ich meine Tools eben so konfiguriert habe dass sie reine Whitespace Änderungen ignorieren.