Windows Dev Container shows hundreds of modified files immediately after opening

[DiwanshuG]

Hi!

I'm working on fixing issue #4765.

I was able to reproduce the bug and have a working fix locally , fixes the JPEG EXIF orientation issue).

Before opening the PR, I noticed a Git problem when using the provided Dev Container on Windows.

My workflow:

1. Clone my fork on Windows.
2. Open the repository in VS Code.
3. Reopen in the provided Dev Container.
4. Run git status.

On Windows:

git status

Output:

On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

Immediately after opening the Dev Container (without editing any files):

git status

Git reports hundreds of modified files.

I also checked:

git ls-files --eol README.md

Output:

i/lf    w/crlf    attr/    README.md

The repository doesn't seem to contain a .gitattributes file.

Is there a recommended workflow for Windows contributors using the Dev Container?

• Should the repository be cloned inside WSL instead of a Windows drive?
• Is there a Git configuration I should use?
• Or is there another recommended setup?

I'd like to submit a clean PR containing only the fix for issue #4765.

Thanks!

[Thominho]

Your git ls-files --eol output already contains the answer:

i/lf w/crlf attr/ README.md

i/lf — LF in the index. w/crlf — CRLF in your working tree. attr/ — empty, so no .gitattributes rule applies.

Git for Windows sets core.autocrlf=true in its system config, so git clone wrote every text file to disk with CRLF while the index kept LF. Nothing in this repository caused it.

Why the host is clean but the container is dirty

With autocrlf=true, Git converts CRLF back to LF in memory before diffing, so it sees no change. The Dev Container runs Linux, where core.autocrlf defaults to false. That Git compares the raw CRLF bytes on disk against the LF blobs in the index and flags every text file as modified. Same files, same bind mount, different conversion setting.

Minimal reproduction:

$ git ls-files --eol           # after clone with autocrlf=true
i/lf    w/crlf  attr/    file.txt

$ git status --porcelain       # host: clean
$ git -c core.autocrlf=false status --porcelain
 M file.txt                    # container's view: modified

Fixing the clone you already have

Changing the setting alone does nothing — the files have to be rewritten:

$ git config core.autocrlf input
$ git rm --cached -r .
$ git reset --hard

I verified both halves: after the config change alone, git ls-files --eol still shows w/crlf and the container still reports M; after the re-checkout it shows w/lf and the container is clean. Do this before you start branching, since git reset --hard discards uncommitted work.

Alternatively, clone into the WSL2 filesystem (\\wsl$\..., not /mnt/c/...). Git there defaults to autocrlf=false, so files land as LF — and Dev Containers are substantially faster on ext4 than over a Windows bind mount.

For the repository itself

A .gitattributes at the root would fix this for every Windows contributor regardless of their local config:

* text=auto eol=lf

I tested this as well: with that file committed, a fresh clone on a machine with autocrlf=true still checks out LF and the container's view stays clean. Probably worth a separate PR from your #4765 fix.

Your three questions

• WSL instead of a Windows drive? Recommended, mainly for performance — it fixes line endings as a side effect.
• A Git configuration? core.autocrlf=input, plus the re-checkout above.
• Another setup? .gitattributes in the repo is the durable one — it removes the need for every contributor to configure anything.

Your working tree isn't actually modified, only the byte-level comparison differs. Once git ls-files --eol shows w/lf, your PR will contain nothing but the #4765 fix.

[NissanBoss]

Thominho's diagnosis is right, and your own git ls-files --eol output confirms it: i/lf w/crlf means the blobs are LF and your working tree is CRLF, so the Linux container reads every one of them as modified.

One thing worth adding to the fix, because it can cost you work. git reset --hard discards any uncommitted changes along with the line endings. If you have edits in there you care about, the safer way to apply a new .gitattributes is:

git add --renormalize .
git status

That rewrites the index entries to match the attributes without touching your working tree, so you can see the normalisation as a single reviewable change and commit it. Same result, and nothing is lost if you were mid-edit.

On your third question: cloning into the WSL2 filesystem is worth doing for a dev container whatever the line endings do. A bind mount from a Windows path into a Linux container goes through a translation layer, and file watching and dependency installs are noticeably slower through it.