Cloning a git repo, and it already has a dirty working directory... Whaaaaa?

Solution 1:

Which OS are you using? This error is caused by your filesystem not being case sensitive, like the default on Mac OS X.

Solution 2:

So, you've checked out linux sources on a filesystem that isn't case sensitive. That's the problem. Try checking out on ext2 partition.

As a workaround you can also use git sparsecheckout feature:

git config core.sparsecheckout true
echo /* > .git/info/sparse-checkout 
echo !include/linux/netfilter/ > .git/info/sparse-checkout 
echo !include/linux/netfilter_ipv4/ > .git/info/sparse-checkout 
echo !include/linux/netfilter_ipv6/ > .git/info/sparse-checkout 
echo !net/ipv4/netfilter/ > .git/info/sparse-checkout 
echo !net/netfilter > .git/info/sparse-checkout
git read-tree --reset -u HEAD

Solution 3:

Hit the same problem but it has been almost 8 years, Windows now supports case sensitive folder.

fsutil.exe file setCaseSensitiveInfo <folder path> enable

Then resync the folder. Note this will not affect subdirectory so need to run this command for every folder.

Solution 4:

This error is caused by your filesystem not being case sensitive

You should not have to guess anymore, not with Git 2.20 (Q4 2018, seven years later after the OP)

It is true that running "git clone" against a project that contain two files with pathnames differing only in cases on a case insensitive filesystem would result in one of the files lost because the underlying filesystem is incapable of holding both at the same time.
But now... an attempt is made to detect such a case and warn.

See commit b878579 (17 Aug 2018) by Duy Nguyen (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit c240732, 17 Sep 2018)}

clone: report duplicate entries on case-insensitive filesystems

Paths that only differ in case work fine in a case-sensitive filesystems, but if those repos are cloned in a case-insensitive one, you'll get problems. The first thing to notice is "git status" will never be clean with no indication what exactly is "dirty".

This patch helps the situation a bit by pointing out the problem at clone time.
Even though this patch talks about case sensitivity, the patch makes no assumption about folding rules by the filesystem. It simply observes that if an entry has been already checked out at clone time when we're about to write a new path, some folding rules are behind this.

In the case that we can't rely on filesystem (via inode number) to do this check, fall back to fspathcmp() which is not perfect but should not give false positives.

You can see unpack-trees.c with a new report_collided_checkout() function, which will display the warning:

the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

No more surprises here.

codewarrior mentions in the comments that Windows does support now (2018-2019) case sensitive filesystem with fsutil.exe file setCaseSensitiveInfo C:\a\path enable ...
Yes but, as seen in MicrosoftDocs/windowsserverdocs issue 977:

You have to enable Windows Subsystem for Linux before this will work.

Run the following command as Administrator in PowerShell to enable this optional feature:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

You'll be prompted to restart your machine once it's installed.
After your computer restarts, you'll be able to run Fsutil as Administrator in a command prompt window as you expected.

See "Per-directory case sensitivity and WSL"

Starting with Windows insider build 17093, we’ve introduced a new way to handle case sensitive files in Windows: per-directory case sensitivity.
We use this ability in the Windows Subsystem for Linux to give you better interoperability when using case sensitive files, and you can also use it yourself with regular Windows applications.

Starting with build 17110, DrvFs’s default behavior is now equivalent to using “case=dir”.
This means that any directories you created with WSL before build 17093 will not be treated as case sensitive anymore. To fix this, use fsutil.exe to mark your existing directories as case sensitive.

Solution 5:

The comments are most likely correct in their suspicion of line endings. Try setting this option:

git config --global core.autocrlf true

Then re-clone the repository.

Use a value of true on windows and input on OSX/Unix.

Take a look at this Github help page for more information.