Solving Git Sync Issues Caused by Different System Line Endings

Share & showcase
1

Introduction

First, this article is not written for most users; it only applies to users who meet these two conditions:

  1. You use multiple platforms (Windows and iOS/macOS/Linux)

  2. Your synchronization method includes Git

Under these circumstances, you’ll typically encounter numerous ineffective syncs due to line ending differences. While this doesn’t affect the content, it can be quite annoying.

In the GitHub client, it looks like this:

241122_解决不同系统换行符号导致的Git同步问题-img-241124_220617

Known as Only whitespace changes found.

I saw many users in this topic ( Being able to select line endings CRLF - LF - Feature requests - Obsidian Forum) bothered by this issue, too.
And I hope this article could help others solve this issue.

Conclusion

To summarize in one sentence: ==Use LF as the line ending on all systems==

Windows historically used CRLF, which is the main source of most conflicts.

Apple and Linux use LF, and Obsidian’s default line ending is also LF [1].

Moreover, compared to CRLF’s \r\n, LF’s single \n is cleaner, so in conclusion, we’ll standardize on LF.

There are several steps to accomplish this.

[!ref]

[[240118_使用Git同步Obsdian|Using Git to Sync Obsidian]] — particularly focusing on [[240118_使用Git同步Obsdian.md#行末尾 CRLF 的问题|CRLF Line Ending Issues]]

[[240228_Mac端自动同步Git的研究|Research on Automatic Git Sync for Mac]]

Configuring Git

In the .gitattributes file:


# Auto detect text files and perform LF normalization

* text=auto eol=lf

# From: https://forum.obsidian.md/t/being-able-to-select-line-endings-crlf-lf/5294/14

*.md text eol=lf

*.txt text eol=lf

*.css text eol=lf

*.js text eol=lf

*.json text eol=lf

*.py text eol=lf

—This specifies that all common text files should use LF for line endings.

Additionally, regarding automatic conversion, another Q&A mentioned in the discussion[2] suggests:


git config --global core.autocrlf false

This means do not automatically convert line endings.

Follow this configuration by running the command in the terminal.

You can also use git config --get core.autocrlf to check the current configuration.

Renormalization


git rm --cached -r .

git reset --hard

git add .

(The following is AI’s response)

git reset --hard is a dangerous command that will:

  1. Reset the HEAD of the current branch to the last commit

  2. Reset the staging area

  3. Most importantly: forcibly reset all files in the working directory to their state at the last commit

This means:

  • All uncommitted modifications will be discarded

  • All unstaged changes will be discarded

  • The working directory will exactly match the state of the last commit

I apologize for previously suggesting this command directly, as it could lead to data loss. For handling line endings, we can use a safer approach:


# 1. First commit current changes (if any)

git add .

git commit -m "Save current changes"

# 2. Then renormalize files

git add --renormalize .

git commit -m "Normalize line endings"

Cleaning Commit History

Finally, if Git already shows many files with Only whitespace changes found:

241122_解决不同系统换行符号导致的Git同步问题-img-241122_114448
241122_解决不同系统换行符号导致的Git同步问题-img-241122_1144481082×660 102 KB

You can use:


git add --renormalize .

This command will convert all files to use the configured line ending—which is LF as we set above.

Theoretically, this should ensure all files in the Git repository use consistent line endings.

Then, if we configure all our text editors on Windows to use LF line endings, there should be no major issues.

  1. Discussion thread about this: 【Bug】: CRLF would be replaced by LF · Issue ＃164 · Vinzent03/obsidian-git ↩︎

  2. StackOverflow Q&A: eol - git commit get fatal error “fatal: CRLF would be replaced by LF in” - Stack Overflow ↩︎

1 Like