Re: AI Textconv filter misconfiguration on Windows leads to silent corruption of diff output (ongoing investigation)

" So as Randall says, don't tell Git files are text if they aren't :) Using "* text=auto" might be safer (allowing Git to decide whether a file is text) if you need line ending normalization. "

Yeah, same conclusion as AI.

But the real question is:

1. How to do that ?

2. Is it truely safe ? Or will it lead to further problems.

3. I don't have time to read obscure old git manuals from the 70's about * and all kinds of strange rules.

^ Thus I do believe I have a slight point here, the command line is ancient enough already, apperently it requires some .gitattribute file and set blabla * text * png * bmp.

The whole thing does not make much sense to me, the syntax don't make much sense.

* is in ms-dos everything... so using this in this way in git is bizar/strange/alien/non-intuitive/can't wrap my head around, doesn't make any sense... etc ?! Get the vibe ?

Also my 4th though is:

4. Do I then have to do this for every possible binary file and tell git which files are binary ? The whole thing kinda stinks... but maybe there is no other solution.

For now I have "better" or "other" things to do then keep experimenting with this dangerous stuff for something as silly as CR LF in text files.

For now the AI advised me to delete .gitattributes and I did just that and will continue using a more or less default installation from GIT to prevent any corruption which would be horrible.

Yesterday I wrote two programs with AI:

1. One to scan 68 repositories which were posted online to make sure they were not corrupted, thankfully non of them was corrupted.

2. A git repo finder/scanner which scans my folders for .git folders from a certain date. Thankfully Co-Pilot still remembered at what date I enabled this flawed git filter.

So finding those repos was kinda easy. I found about 3 to 4 or something so far. At least one of them had corrupted PNGs as well. (Doc folders)

Two of them I re-cloned just in case...

So far I have been kinda lucky to find this issue with 2 months and have had not too much git cloning activity... it could have turned into a much bigger disaster if text files were corrupted instead of binary files.

Binary files kinda rare in git repos and with a bit of luck they don't have CR/LF in them... Text files on the other hand are everywhere in git... text file corrupted would have been a major problem.

For me a simpler solution where git has some kind of "list" of files, and then enable/disable...

Maybe some list which tells git if it's binary or not.

Something simple like:

PNG binary BMP binary TXT text PAS text DPR text JPG binary

That would make more sense to me, without the * etc... why is the * asterix necessary at all ?

However I would demand a pre-made list... because this is kinda nuts to do this yourself.

Plus, this is still not ideal.

What if an application saves files in a known extension from this list, it's supposed to be binary... but will be mistreated as text...

I guess this is the risk with git after all or maybe not, maybe you have a point with auto detection.

It would be amazing if git detects a *.pas as being binary... because some tool happens to use that as it's data files.

So for now, I would agree with you auto detection maybe best, but why does this not solve the diff problem with ^M everywhere ? Hmmm.

Bye for now,
  Skybuck.