上下文
我正在使用gitlab，并在某些仓库中维护一些UTF-16 LE编码INI文件。我看到使用Tortoisegit下载该文件，我看到BOM，文本在Vscode中看起来不错，该文件识别为UTF-16 LE，带有CRLF的预期新线等。问题是在下载一些Zip Archive Gitlab时能够生成时。 。
在那些情况下，一个文件将所有字节替换为0x0d0a，实际上将LF更改为CRLF。问题是根本不需要它，因为该文件正确包含了UTF 16 LE编码后已经已经包含的CRLF。即使是必要的，对于UTF-16 LE来说，将一个字节更改为两个字节也是错误的，它也会缺少以这种方式额外的0x00。最后，结果无法正确渲染。
src =“ https://i.sstatic.net/vmpld.png” alt =“错误newline bytes”>
更新 .gitaTtributes
首先，我错误地将文件定为错误，因为我希望它会使用 Windows-1252 对其进行编码。适用以下规则：
* text=auto
*.ini text eol=crlf working-tree-encoding=windows-1252
我已将其更改为以下，执行 git add-enferalize。，犯罪，推动，事物似乎可以正常工作：
* text=auto
*.ini text eol=crlf working-tree-encoding=windows-1252
0x0409.ini diff -text -working-tree-encoding
/Driver-DalsaFG/77593-Teledyne_Dalsa_Xcelera_CL_LX1_device_driver/0x0409.ini diff -text -working-tree-encoding
Web-UI现在显示文件的内容我能够通过适当的线结尾和编码下载一个单独的文件。以前不是这种情况。但是，使用Web-UI或API为某些分支生成ZIP仍然无法解决文件内容的上述问题。
gitlab
我想在Gitlab上为此问题添加一个其他问题，他们建议创建一个存储库来证明该问题作为问题报告的一部分。因此，我做到了这一点，并认识到我的问题没有发生在存储库中。我唯一要做的就是创建回购，克隆它，将文件添加为IS，投入和推动。不过，下载的zip中的文件看起来还不错。因此，我在Gitlab中使用了一个新的存储库尝试了同样的事情，也发生了同样的事情，邮政编码中的文件还可以。
额外的提交使所有现有数据失败失败了，
奇怪的事情就是：当我在具有正确的 .gitattributes 的附加subdir中再次提交完全相同的文件时，该文件在zip中是正确的。如果 .gitAttributes subdir中的文件仅是错误的，则zip中所有其他相同的文件也是错误的。在某些测试用例中，我可以通过简单地使 .gitattributes 再次更正并应用于所有文件来解决此问题，但是在某些测试用例中，这还不够。该测试发生在不同的存储库中，一个是新创建的，另一个包含实际关注的数据。
当Git通过其哈希而不是路径跟踪内容时，我感到它可能会决定在创建ZIPS时决定使用服务器存储库中可用的错误数据，并且我无法让它决定其他方式。如果 .gitAttributes 在创建ZIP时只会有所作为，则只能通过进行这些更改来在工作和非工作文件之间切换。但是我不是，只有在某些测试案例中，这似乎有所帮助。
问题
是否有任何方法可以用本地可用的内容覆盖GitLab在GitLab上维护的Git-Internal数据？几乎就像力量推动一样，但是即使在客户的情况下，也没有任何实际的更改。因为更改 .gitattribute 不会导致我的工作副本的更改，甚至 git add add -renforalize。没有任何区别。很可能是因为该文件在某个时候自动用作二进制。
谢谢！
Context
I'm using GitLab and maintain some UTF-16 LE encoded INI file in some repo. Downloading that file using TortoiseGIT looks good, I see the BOM, the text looks good in VSCode, that recognizes that file as UTF-16 LE with the expected newlines of CRLF etc. The problem is when downloading some ZIP archive GitLab is able to generate.
In those cases that one file gets all bytes of 0x0A getting replaced to 0x0D0A, actually changing LF to CRLF. The problem is that it's not needed at all, because the file properly contains CRLF already following UTF 16 LE encoding. Even if it was necessary, changing one byte to two only is wrong for UTF-16 LE as well, it's missing the additional 0x00 per byte this way. In the end, the result can't be rendered properly.
Updating .gitattributes doesn't help
At first I've committed the file wrongly, because I expected it to be encoded using windows-1252. The following rule applied:
* text=auto
*.ini text eol=crlf working-tree-encoding=windows-1252
I've change that to the following, executed git add --renormalize ., committed, pushed and things seem to work OK:
* text=auto
*.ini text eol=crlf working-tree-encoding=windows-1252
0x0409.ini diff -text -working-tree-encoding
/Driver-DalsaFG/77593-Teledyne_Dalsa_Xcelera_CL_LX1_device_driver/0x0409.ini diff -text -working-tree-encoding
The web-UI showed contents of the file now and I was able to download that one individual file with proper line endings and encoding. That wasn't the case before. Though, generating a ZIP for some branch using the web-UI or the API still doesn't work with the above problems of the file content.
Known issues at GitLab
I wanted to add an additional issue for this problem at GitLab and they suggested to create a repo to demonstrate the problem as part of issue reporting. So I did that and recognized to my surprise that the problem didn't occur in the repo. The only thing I did was creating the repo, cloning it, adding my files as-is, committing and pushing. Though, the file in the downloaded ZIP looked OK. So I tried the same with a new repo in my GitLab and the same happened as well, the file in the ZIP was OK.
Additional commits make ALL existing data fail
The strange thing is the following: When I commit the exactly same file again in an additional subdir with correct .gitattributes, the file is correct in the ZIP. If the .gitattributes for the file in the subdir ONLY are wrong, ALL other same files are wrong in the ZIP as well. In some test cases I was able to fix this by simply making the .gitattributes correct again and apply to all files, but in some test cases this wasn't sufficient. The test happened in different repos, one created newly and the other one containing the data of actual interest.
As GIT tracks content by its hashes instead of paths, I have the feeling it might decide to use the same wrong data available at the server repo when creating ZIPs and I'm unable to get it to decide otherwise. If .gitattributes only would make the difference when creating the ZIP, I would be able to switch between a working and non-working file only by committing those changes. But I'm not, only in some test cases this seems to help.
Question
Is there any way to overwrite the GIT-internal data maintained at GitLab with what's available locally? Pretty much like a force push, but even in cases the client doesn't have any actual changes committed. Because the changes to .gitattribute don't result in changes in my working copy, even git add --renormalize . doesn't make any difference. Most likely because the file is automatically used as binary at some point.
Thanks!
发布评论