Re: git clone corrupts file.

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Aug 16, 2021, 21:50 UTC
Message-ID: <YRrdq5VAp3o35+Fb@camp.crustytoothpaste.net>
In-Reply-To: <YRqzmC5ubd0TEWL/@coredump.intra.peff.net>

On 2021-08-16 at 18:51:04, Jeff King wrote:

Show 13 quoted lines

> 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