RE: git clone corrupts file.
- From
- Russell, Scott <scott.russell2@ncr.com>
- Date
- Aug 16, 2021, 18:52 UTC
- Message-ID
- <BN6PR15MB14261548DE31763B34CEEDD5CBFD9@BN6PR15MB1426.namprd15.prod.outlook.com>
- In-Reply-To
- <YRqzM1D6w4bDYjKY@coredump.intra.peff.net>
Jeff,
Thanks for your response. I will try these suggestions. I suspect I can come to some solution.
Thanks,
Scott Russell
Staff SW Engineer
NCR Corporation
Phone: +17706237512
Scott.Russell2@ncr.com | ncr.com
-----Original Message----- From: Jeff King <peff@peff.net> Sent: Monday, August 16, 2021 2:49 PM To: Russell, Scott <Scott.Russell2@ncr.com> Cc: brian m. carlson <sandals@crustytoothpaste.net>; git@vger.kernel.org Subject: Re: git clone corrupts file.
*External Message* - Use caution before opening links or attachments
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.
Show 6 quoted lines
> 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.
Show 14 quoted lines
> 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