Enforce core.autocrlf=input through .gitattributes

前端 未结 3 2057
梦毁少年i
梦毁少年i 2021-02-14 10:42

Is there a way to enforce core.autocrlf=input from within the .gitattributes in order to propagate the policy throughout my colleagues?

In deta

相关标签:
3条回答
  • 2021-02-14 11:30

    The closest thing to core.autocrlf=input is to use text=auto in .gitattributes.

    That specifies they are text files, so new files will be put in the repo with LF line endings. And, according to The gitattributes documentation, by setting text=auto:

    When the file has been committed with CRLF, no conversion is done.

    We converted a Mercurial repo to Git recently. Mercurial does no eol conversions, so many of our files already had CRLF after the conversion. Setting text=auto for those file extensions allows new files to still be normalized to LF, but doesn't touch the existing files, and doesn't show them as modified in the current directory.

    0 讨论(0)
  • 2021-02-14 11:37

    In detail what I want is to convert to lf on commit and leave as is on checkout.

    Git doesn't convert on commit, but rather on git add. (More precisely, it does conversions on operations that copy the object into the repository and produce a hash value—but for most purposes, that's just git add anyway.) At this time it applies any "clean" filters and does input-side EOL operations. (Likewise, output-side "smudge" filters and EOL operations occur when copying out from the repository to the work-tree, which for most purposes is git checkout and git reset --hard.)

    According to the gitattributes documentation, setting eol=lf:

    ... forces Git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out.

    Hence, though I have not actually tested this, it sounds like * eol=lf is just what you want. Note that this is different from core.eol, which behaves as you described in your question; this is only for a .gitattributes setting, which applies to the files that match the name-pattern.

    0 讨论(0)
  • 2021-02-14 11:42

    It isn't clear exactly what you mean by "as is" in the working tree. If you want Git to store line endings in LF in the repository and let the user decide what they want in the working tree (based on their platform and/or settings), then use this:

    * text
    

    That will force line ending conversion on, and Git will convert files to LF in the repository and will honor the user's preferred line endings on checkout. If not all of your files are text (i.e., you have images or other binaries) and you'd like Git to guess, then you can use this:

    * text=auto
    

    Note that as mentioned by LoopInFool, this will not cause files that are already CRLF to be converted, so you'll need to be sure that your files are already in LF in the repository, or list those files types explicitly as text (e.g., *.c text).

    The behavior of core.autocrlf=input is to force conversion to LF on addition into the repository and not to perform any conversion on checkout; that is, to always use LF endings regardless of the user's settings. If that's the behavior you want, then you can do that with the following:

    * eol=lf
    

    Note that setting eol effectively sets the text attribute, so you should not set it on any files that are binary.

    If what you want is for Git to match the line endings that are already in the working tree on checkout (e.g, by reading the file), then it won't do that. Git always does line ending conversions based on configuration without regard to what's already there, so the user will have to indicate their preference in some way or accept the platform default behavior.

    In addition, Git always counts any modification to the file size as a modification in git status, even if it ignores those changes on add (say, because you've only changed line endings); this is similarly not avoidable.

    If what you want is something entirely different, please go into a little more detail about what behavior you want, and I'll update with more details.

    0 讨论(0)
提交回复
热议问题