RE: git clone corrupts file.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Brian,  

I appreciate the guidance.   All our .h files can call be converted to ANSI.   I don't know why we seemed to have just one saved as Unicode. 
But it was a wakeup, and led to discovery of other files not correct.  

Upon reading the help on .gitattributes, I was reminded that Windows Visual Studio can save some .rc files as Unicode.  
I think that most all are ANSI but that leaves the possible result that any one saved as Unicode could unexpectedly fail compiling due to the conversion.  

We have a mix of *.ini files which are a mix of mostly ANSI and more than a few others are Unicode.  
I don't know how to handle a mixture.

Perhaps I will have to specify 

*.ini -text.  

Unless, does .gitattributes allow paths to be specified?  In effect use the 

Path/path/path/*  text lf=crlf working-tree-encoding=UTF-16LE-BOM

And otherwise, 
*.ini text 	- these would be ansi if not in path/path/path  

Thanks, 

Scott Russell
Staff SW Engineer 
NCR Corporation 
Phone: +17706237512
Scott.Russell2@xxxxxxx  |  ncr.com
       

-----Original Message-----
From: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> 
Sent: Monday, August 16, 2021 5:51 PM
To: Jeff King <peff@xxxxxxxx>
Cc: Russell, Scott <Scott.Russell2@xxxxxxx>; git@xxxxxxxxxxxxxxx
Subject: Re: git clone corrupts file.

*External Message* - Use caution before opening links or attachments

On 2021-08-16 at 18:51:04, Jeff King wrote:
> On Mon, Aug 16, 2021 at 12:53:36PM -0400, Jeff King wrote:
> 
> > But an alternative workflow, if you really want UTF-16 in the 
> > working tree, is to convert between UTF-8 and UTF-16 as the files go 
> > in and out o the working tree. There's no built-in support for that, 
> > but you could do it with a custom clean/smudge filter. That would 
> > let Git store UTF-8 internally, do diffs, etc.
> 
> Oh, by the way, I totally forgot that we added an internal version of 
> this, which is easier to configure and much more efficient. See the 
> "working-tree-encoding" attribute in "git help attributes".
> 
> Just in case you do want to go that route.

The specific information you need is located in the Git FAQ[0], but roughly, you would probably want something like this:

*.h text lf=crlf working-tree-encoding=UTF-16LE-BOM

That means that when checked out, the file will be in the format that legacy Windows programs prefer (CRLF with little-endian UTF-16 with a BOM), but will be stored internally in Git with LF and UTF-8.  That will make things like git diff work much better, but still permit things to be in the working tree as you wish.

If you really don't want those to be modified at all, then you'd want to write this:

*.h -text

However, Git will consider these files to be binary, since they are, and git diff won't work on them without a textconv filter.

[0] https://git-scm.com/docs/gitfaq#windows-text-binary
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux