The Wiert Corner – irregular stream of stuff

Start with this must read post: cross platform – What’s the best CRLF handling strategy with git? – Stack Overflow.

Then read all the links in that answer, especially

• Git – gitattributes Documentation.
• Dealing with line endings · GitHub Help.
• Mind the End of Your Line ∙ Timothy Clem ∙ Adaptive Patchwork.

Then see if you agree with my conclusion:

use a .gitattributes file to steer line ending conversions on a per-repository base.

I usually try to have git not mess with any line endings: check-out as-is, check-in as is.

Historically this has been a mess (not limited to, but prevalent on Windows installations), not just because core.autocrlf has been superseded by core.eol, so below are some links that will help.

TL;DR

Always execute these after installing git:

git config --global core.autocrlf false
git config --global core.eol native

If needed, repeat in the current repository:

git config --local core.autocrlf false
git config --local core.eol native

Finally verify the settings with git config --list --show-origin (via [WayBack] Where does git config –global get written to? – Stack Overflow)

Note

The git config list will show equals signs. Do NOT use these when setting values: that will silently fail.

So these fail:

git config --global core.autocrlf=false
git config --global core.eol=native

git config --local core.autocrlf=false
git config --local core.eolnative

Despite the output when listing on a machine that already had these values et:

git config --list | grep -w 'core.autocrlf\|core.eol'
core.autocrlf=false
core.eol=native
core.autocrlf=false
core.eol=native

References

• [WayBack] Dealing with line endings – User Documentation
• [WayBack] Git – gitattributes Documentation: text:
  • core.autocrlf overrides core.eol
  • Unsetting the text attribute on a path tells Git not to attempt any end-of-line conversion upon checkin or checkout.
  • If core.safecrlf is set to “true” or “warn”, git verifies if the conversion is reversible for the current setting of core.autocrlf. For “true”, git rejects irreversible conversions; for “warn”, git only prints a warning but accepts an irreversible conversion.
• [WayBack] Git – gitattributes Documentation: end of line conversion
• [WayBack] Source: Git – git-config Documentation: core.eol
• [WayBack] Source: Git – git-config Documentation: core.autocrlf
• [WayBack] Source: Git – git-config Documentation: core.safecrlf
• [WayBack] line endings – Why should I use core.autocrlf=true in Git? – Stack Overflow
• [WayBack] newline – How line ending conversions work with git core.autocrlf between different operating systems – Stack Overflow

  •                  | Resulting conversion when       | Resulting conversion when 
                     | committing files with various   | checking out FROM repo - 
                     | EOLs INTO repo and              | with mixed files in it and
                     |  core.autocrlf value:           | core.autocrlf value:           
    --------------------------------------------------------------------------------
    File             | true       | input      | false | true       | input | false
    --------------------------------------------------------------------------------
    Windows-CRLF     | CRLF -> LF | CRLF -> LF | as-is | as-is      | as-is | as-is
    Unix -LF         | as-is      | as-is      | as-is | LF -> CRLF | as-is | as-is
    Mac  -CR         | as-is      | as-is      | as-is | as-is      | as-is | as-is
    Mixed-CRLF+LF    | as-is      | as-is      | as-is | as-is      | as-is | as-is
    Mixed-CRLF+LF+CR | as-is      | as-is      | as-is | as-is      | as-is | as-is
    

  • I explored 3 possible values for commit and checkout cases and this is the resulting table:

    ╔═══════════════╦══════════════╦══════════════╦══════════════╗
    ║ core.autocrlf ║     false    ║     input    ║     true     ║
    ╠═══════════════╬══════════════╬══════════════╬══════════════╣
    ║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
    ║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
    ║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => CRLF ║
    ╠═══════════════╬══════════════╬══════════════╬══════════════╣
    ║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
    ║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
    ║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
    ╚═══════════════╩══════════════╩══════════════╩══════════════╝

• [WayBack] windows – Why does git keep messing with my line endings? – Stack Overflow
• [WayBack] Mind the End of Your Line ∙ Adaptive Patchwork
• [WayBack] Configuring how line-endings are handled by git – SCAPE – Confluence

–jeroen

PS: To look at the various local and global settings, read Where does git config –global get written to? – Stack Overflow.

Every now and then I forget to git config --local user.name and git config --local user.email, so git takes my global settings and I need to fix one or more commits to it shows the correct author.

For the last commit, when not yet pushed, this is easy:

git commit --amend --author="Author Name <email@address.com>"

For historic commits, or when you already pushed, it gets far more difficult, so I am glad there is a good set of steps at [WayBack] git – Change commit author at one specific commit – Stack Overflow.

For now in my %USERPROFILE%\.gitconfig file, I have added entries for various accounts so it is easier to spot them with git config --list --global then edit them using git config --edit --local:

[user.foo]
    name = jeroenfo
    email = ########+jeroenfoo@users.noreply.github.com
[user.gh]
    name = Jeroen Wiert Pluimers
    email = jeroen.vvv.www@pluimers.com
[user.gl]
    name = Jeroen Wiert Pluimers
    email = jeroen.xxx.yyy@pluimers.com

If you pushed, but nobody pulled, and you are the only one committing, then the steps are like this if your git is 1.8 or higher:

1. Once,
   1. perform git rebase -i --root
   2. at all commits you want to edit, change pick into edit
   3. write the file, then leave the editor (:wq)
2. For each commit, until git indicates No rebase in progress?:
   1. perform git commit --amend --reset-author --no-edit
   2. perform git rebase --continue

–jeroen