Re: Suggested clarification for .gitattributes reference documentation

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

 





On Sat, 13 Jan 2024, Torsten Bögershausen wrote:

On Sat, Jan 13, 2024 at 02:56:27AM +0000, Michael Litwak wrote:
I just installed Git for Windows 2.43.0 and noticed the installer offers three options for altering the PATH:

1) Run git from git bash only

2) Run git from git bash, cmd.exe and PowerShell (RECOMMENDED)

3) Run git from git bash, cmd.exe and PowerShell with optional utilities (warning: will override find, sort and other system utilities).

It turns out iconv.exe is accessible from cmd.exe (Command Prompt) only when you take the third option.  But iconv.exe is NOT optional.  It is required for git to deal with UTF-16LE with BOM text conversions (and probably for numerous other encoding conversions).

For end users directly calling iconv.exe is definitely optional.

Plese wait a second - and thanks for bringing this up.
To my knowledge the binary iconv.exe (or just iconv under non-Windows)
is never called from Git itself.
Git is using iconv_open() and friends, which are all inside
a library, either the C-library "libc", or "libiconv"
(not 100% sure about the naming here)

Exactly. I can't find a single instance of Git for Windows calling iconv.exe instead of using the corresponding library functions. [1]

And even if it did, iconv.exe is definitely on the path for git.exe [2] unless you're calling /(mingw|clangarm)(64|32)/bin/git.exe directly, in which case the solution is to call /cmd/git.exe instead.

[1] https://github.com/search?q=repo%3Agit-for-windows%2Fgit%20iconv%20NOT%20path%3A%2F%5Et%5C%2F%2F%20NOT%20path%3A%2F%5EDocumentation%5C%2F%2F&type=code [2] https://github.com/git-for-windows/MINGW-packages/blob/0c91cf2079184ae6a604e8f7a406a47d39305e72/mingw-w64-git/git-wrapper.c#L166-L258

iconv.exe is not needed in everyday life, or is it ?
If yes, when ?
iconv.exe is used when you run the test-suite, to verify
what Git is doing.

Could you elaborate a little bit more,
when iconv.exe is missing, and what is happening, please ?


But when PATH option #2 is chosen, and iconv.exe is unreachable from a Windows Command Prompt, the git commands which call upon iconv.exe do NOT indicate the error.  The call to iconv.exe fails silently.  It is only later after you commit, push and clone the repo again that you see the encoding failures.

And the warning about overriding find and sort must be taken with a grain of salt, since the Windows versions of those programs are accessed via a Windows folder which appears earlier in the PATH.

We should probably consider rewording that warning.

So this Git for Windows installer screen is misleading.  And perhaps iconv.exe should be relocated so it is accessible even when PATH option #2 is chosen.  I intend to submit an issue on the Git for Windows issue tracker regarding this.  I'll also submit an issue about the lack of an error when running 'git add' for a UTF-16LE with BOM file under PATH option #2.

Thanks,
- Michael

[]





[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