为什么在新克隆后文件被视为已修改?什么时候git add --renormalize.用过的? [英] Why are files seen as modified after fresh clone? When is git add --renormalize . used?

问题描述

我对新的git克隆后被修改的文件有疑问.

I have a problem with files which are seen as modified after a fresh git clone.

• 所有文本文件应具有eol=LF，但*.txt文件应具有eol=CRLF.
  

• all text files shall have eol=LF, except *.txt files which shall have eol=CRLF.
  

.gitattributes的外观如下:

Here's how .gitattributes looks like:

*       text=auto
*.txt   text  eol=crlf
*.png binary
*.jpg binary
*.bmp binary

这是我的测试:

Here's my tests:

• 带有2个.txt文件(LF.txt和CRLF.txt)的新存储库
  • LF.txt:eol = LF(整个文件中的行尾为LF)
  • CRLF.txt:eol = CRLF(整个文件中的行尾为CRLF)
  • new repo with 2 .txt files (LF.txt and CRLF.txt)
    • LF.txt: eol=LF (end of line is LF in the whole file)
    • CRLF.txt: eol=CRLF (end of line is CRLF in the whole file)
    • LF.txt:eol现在是CRLF(符合预期)
    • CRLF.txt被视为已修改，即使它仍具有CRLF作为eol
    • LF.txt: eol is now CRLF (as expected)
    • CRLF.txt is seen as modified, even if it still has CRLF as eol
    • 带有2个.txt文件(LF.txt和CRLF.txt)的新存储库
      • LF.txt:eol = LF
      • CRLF.txt:eol = CRLF
      • new repo with 2 .txt files (LF.txt and CRLF.txt)
        • LF.txt: eol=LF
        • CRLF.txt: eol=CRLF
        • CRLF.txt被视为已修改并已上演(但没有内容差异，并且eol仍为CRLF)
        • .gitattributes仍未跟踪
        • CRLF.txt is seen as modified and staged (but there are no content differences and eol is still CRLF)
        • .gitattributes is still untracked
        • LF.txt:eol现在是CRLF(符合预期)
        • CRLF.txt:eol是CRLF(与开头一样)
        • 回购很干净
        • LF.txt: eol is now CRLF (as expected)
        • CRLF.txt: eol is CRLF (as in the beginning)
        • repo is clean
        • 操作系统:Windows 10
        • git版本:2.20.1.windows.1
        1. 测试1:为什么在新克隆后CRLF.txt被视为已修改?
        2. 测试2:git add --renormalize .实际在做什么?为什么还不登台.gitattributes?
        3. 在已经具有一定历史记录的存储库中设置.gitattributes时，是否建议运行git add --renormalize以避免新克隆后修改文件?
        1. Test 1: why is CRLF.txt seen as modified after a fresh clone?
        2. Test 2: what is git add --renormalize . actually doing? Why doesn't it stage .gitattributes also?
        3. When setting up .gitattributes in a repo which already has some history, is it recommended to run git add --renormalize in order to avoid modified files after fresh clone?

        推荐答案

        测试1:为什么在新克隆后CRLF.txt被视为已修改?

        Test 1: why is CRLF.txt seen as modified after a fresh clone?

        因为您撒谎了git:您已经告诉git，存储库中CRLF.txt的行尾是Unix风格(LF)的行尾，但是您想要Windows风格(CRLF)的行尾在您的工作文件夹中.这就是text属性的含义:标准化行尾，以便它们在存储库中具有Unix样式的行尾.

        Because you've lied to git: you've told git that the line endings for CRLF.txt in your repository are Unix-style (LF) line endings, but that you want Windows-style (CRLF) line endings in your working folder. That's what the text attribute means: normalize the line endings, so that they have Unix-style line endings in the repository.

        但是您的第一步步骤是将具有Windows样式的行尾的文件添加到存储库中.

        But your first step was to add the file with Windows-style line endings into the repository.

        因此，git可以查看磁盘上的文件，将其Windows样式(CRLF)行结尾转换为标准格式(Unix样式LF行结尾)，然后将结果与存储库中的内容进行比较.

        So, git can look at the file on-disk, convert its Windows-style (CRLF) line endings to the normal form (Unix-style LF line endings), and compare the results to what's in the repository.

        这些内容不匹配.因此，它认为您已经修改了文件. 那是您重新规范化文件的原因.

        Those contents don't match. Thus, it thinks you've modified the file. That is why you renormalize files.

        测试2:什么是git add --renormalize.到底在干嘛?

        Test 2: what is git add --renormalize . actually doing?

        它将更新文件以匹配您在.gitattributes中声明的内容.添加.gitattributes时，不会更改磁盘上或存储库中文件的内容.但是，您可能(在本例中为 )正在更改关于内容在存储库中存在方式的声明.

        It updates the files to match what you've claimed in .gitattributes. When you add a .gitattributes, you aren't changing the contents of the files on-disk or in the repository. But you may be (and in this case are) changing the claims you're making about the way the contents exist in the repository.

        如果存储库中的内容 实际上不是您声明的内容，那么git add --renormalize会对此进行纠正.

        If the contents in the repository aren't actually what you claimed, then git add --renormalize will correct that.

        为什么它也没有登台.gitattributes?

        Why doesn't it stage .gitattributes also?

        重新规范化仅影响存储库中已存在的文件，它对"所有跟踪的文件新鲜应用'干净'过程，以将其再次强行添加到索引中". (摘自git文档；重点是我的.)

        Renormalization only affects files already in the repository, it applies "the 'clean' process freshly to all tracked files to forcibly add them again to the index." (From the git documentation; emphasis mine.)

        因此，它实际上仅会重新标准化现有的 内容.

        So it truly only renormalizes existing content.

        在已经具有一定历史记录的回购中设置.gitattributes时，是否建议运行git add --renormalize以避免新克隆后修改文件?

        When setting up .gitattributes in a repo which already has some history, is it recommended to run git add --renormalize in order to avoid modified files after fresh clone?

        是的

        这篇关于为什么在新克隆后文件被视为已修改?什么时候git add --renormalize.用过的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！