Re: git clone corrupts file.

[Jeff King <peff@peff.net>]

On Mon, Aug 16, 2021 at 05:39:12PM +0000, Russell, Scott wrote:

> We don't want any EOL handling of any file.  That's why we specify autocrlf false.

Right, but it's not the whole story. autocrlf is an older and broader
mechanism for doing line-ending conversion. From its documentation in
"git help config":

  core.autocrlf
    Setting this variable to "true" is the same as setting the text
    attribute to "auto" on all files and core.eol to "crlf".[...]

You obviously don't want that, but you _also_ don't want to set the text
and eol attributes on individual paths, either.

> We would like git to not any cr lf conversion on any file.   Whether
> they be ANSI or Unicode.   They had the right endings when we checked
> them in.
> We don't want them adjusted.
> 
> Does removing the eol = cr lf fix that?

That might be sufficient. You may also need to drop "text", as well.
Otherwise core.eol will kick in and do conversions. (Sorry, I don't use
Windows and it has been a long time since I looked into these options,
so you may have to do some experimenting).

> 	You said:  UTF-16 ...  can't be treated as "text" by Git.
> 
> We can't make any changes to the files to suit git.   We just need git to store and retrieve files as committed.

Right. That's what it does by default (if you don't set any .gitattributes).

What I mean by "can't be treated as text" is that Git will not correctly
implement text features like CRLF conversion, nor diffs, for such an
encoding. It is effectively a binary file from Git's perspective.

> Will removing the 
> 
> 	eol=cr lf 
> 
> from the line 
> 
> *.ini text 
> 
> from the attributes file stop the issue?
> 
> If not, does .gitattributes allow a path?  Such that we could say 
> 
> \config\Language Specific\*   type  -    If these are Unicode, what would we say here.   Can it not be text?  Then binary?  
> *.ini	text

If you simply drop the attributes entirely, Git will use its
auto-detection to determine whether a file is binary, which looks for
NULs (and UTF-16 files are generally full of them). So I suspect that
would do it. You can also provide the "-text" attribute to override that
and make sure no line-ending conversion is done.

If you want to override a specific file, then yes, you can provide paths
(I don't recall offhand whether we allow backslashes in the patterns;
you may need to use forward slashes). You can also put the pattern "*"
in the "config/Language Specific/.gitattributes" to have it apply only
to that directory (and ones below it).

The patterns are the same as those in .gitignore files; see the section
"PATTERN FORMAT" in "git help ignore".

-Peff