Re: Suggested clarification for .gitattributes reference documentation

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

 



Regarding Git for Windows requiring 'git bash' console to perform text conversion...

>This sounds like a Git for Windows bug.  Rather than documenting it, could you open an issue for it on their project?
>That sounds like a PATH misconfiguration on your part.  Have you checked your PATH settings to make sure that the path including the binary is included?

If it is merely that I need to adjust my PATH so iconv.exe is accessible, that simplifies everything; however, it could possibly be a Git for Windows installer bug (or perhaps the installer offered to change my PATH and I declined).

I'll check out both possibilities.

>We have also documented the UTF-16LE-BOM case specifically in the Git FAQ (git help gitfaq) under "I'm on Windows and my text files are detected as binary".

I'll take a look and perhaps revise my suggested documentation edits.

Thanks,
- Michael

-----Original Message-----
From: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> 
Sent: Friday, January 12, 2024 1:50 PM
To: Michael Litwak <michael.litwak@xxxxxxxx>
Cc: git@xxxxxxxxxxxxxxx
Subject: [EXTERNAL]Re: Suggested clarification for .gitattributes reference documentation

On 2024-01-12 at 21:25:19, Michael Litwak wrote:
>     Please note, Git for Windows does not support UTF-16LE encoding when running git
>     commands from an ordinary Command Prompt.  Use a git bash console instead.

This sounds like a Git for Windows bug.  Rather than documenting it, could you open an issue for it on their project?

> NEW TEXT:
>     
>     You can get a list of all available encodings on your platform with the following command:
>     
>     iconv --list
>     
>     For Git for Windows users the command, above, is only supported when running in a 'git bash' console.

That sounds like a PATH misconfiguration on your part.  Have you checked your PATH settings to make sure that the path including the binary is included?

> CONCLUSION:
> 
> Text files encoded with UTF-16LE with BOM are common in the Windows 
> world, as some versions of Visual Studio will use this as the default 
> encoding for .rc or .mc files.  Solution files, project files and 
> other Visual Studio files can also be in this format.  Other encodings 
> are common, too, e.g. some older versions of PowerShell defaulted to 
> UTF-16BE with BOM for new .ps1 files. Yet users continue to experience 
> encoding errors even when they are using the proper 
> working-tree-encoding in their .gitattributes file.  Part of this is 
> due to the complexity of Git and the number of different platforms it 
> supports.

I should point out that UTF-8 is pretty much the standard these days in many domains, even on Windows.  For example, nobody is going to be pleased if you write a web page in any variant of UTF-16, and some languages, such as Rust, are simply defined to be in UTF-8 and won't work if you put them in any other encoding.  Almost all editors these days do support UTF-8 (without BOM), even on Windows, so we do want to strongly encourage that rather than having people use UTF-16.  The Git FAQ specifically outlines UTF-8 as the recommended way, which is most portable and most functional.

We have also documented the UTF-16LE-BOM case specifically in the Git FAQ (git help gitfaq) under "I'm on Windows and my text files are detected as binary".  Answering questions on Stack Overflow, I realize that nobody actually reads the FAQ, but we did clearly document how to do it.  That being said, I'm not opposed to an additional mention in the
gitattributes(5) page if you want to send an actual patch.
--
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