Resolving Case Sensitivity Issues and Recommended Git Storage Settings

and macOS by default both perform case folding on file names. As a result, it's possible to end up with multiple files or directories whose names differ only in case. Git can handle this just fine, but the file system can store only one of these files, so when Git reads the other file to see its contents, it looks modified. + It's best to remove one of the files such that you only have one file. You can do this with commands like the following (assuming two files `AFile.txt` and `afile.txt`) on an otherwise clean working tree: + ---- $ git rm --cached AFile.txt $ git commit -m 'Remove files conflicting in case' $ git checkout . ---- + This avoids touching the disk, but removes the additional file. Your project may prefer to adopt a naming convention, such as all-lowercase names, to avoid this problem from occurring again; such a convention can be checked using a `pre-receive` hook or as part of a continuous integration (CI) system. + It is also possible for perpetually modified files to occur on any platform if a smudge or clean filter is in use on your system but a file was previously committed without running the smudge or clean filter. To fix this, run the following on an otherwise clean working tree: + ---- $ git add --renormalize . ---- [[recommended-storage-settings]] What's the recommended way to store files in Git?:: While Git can store and handle any file of any type, there are some settings that work better than others. In general, we recommend that text files be stored in UTF-8 without a byte-order mark (BOM) with LF (Unix-style) endings. We also recommend the use of UTF-8 (again, without BOM) in commit messages. These are the settings that work best across platforms and with tools such as `git diff` and `git merge`. + Additionally, if you have a choice between storage formats that are text based or non-text based, we recommend storing files in the text format and, if necessary, transforming them into the other format. For example, a text-based SQL dump with one record per line will work much better for diffing and merging than an actual database file. Similarly, text-based formats such as Markdown and AsciiDoc will work better than binary formats such as Microsoft Word and PDF. + Similarly, storing binary dependencies (e.g., shared libraries or JAR files) or build products in the repository is generally not recommended. Dependencies and build products are best stored on an artifact or package server with only references, URLs, and hashes stored in the repository. + We also recommend setting a linkgit:gitattributes[5] file to explicitly mark which files are text and which are binary. If you want Git to guess, you can set the attribute `text=auto`. + With text files, Git will generally ensure that LF endings are used in the repository. The `core.autocrlf` and `core.eol` configuration variables specify what line-ending convention is followed when any text file is checked out. You can also use the `eol` attribute (e.g., `eol=crlf`) to override which files get what line-ending treatment. + For example, generally shell files must have LF endings and batch files must have CRLF endings, so the following might be appropriate in some projects: + ---- # By default, guess. * text=auto # Mark all C files as text. *.c text # Ensure all shell files have LF endings and all batch files have CRLF # endings in the working tree and both have LF in the repo. *.sh text eol=lf *.bat text eol=crlf # Mark all JPEG files as binary. *.jpg binary ---- + These settings help tools pick the right format for output such as patches and result in files being checked out in the appropriate line ending for the platform. GIT --- Part of the linkgit:git[1] suite

This section discusses how to resolve issues with case sensitivity in file names, including removing conflicting files and adopting a naming convention. It also provides recommended settings for storing files in Git, such as using UTF-8 without BOM and LF endings, and storing text files instead of binary formats. Additionally, it explains how to configure Git attributes to mark files as text or binary and specify line-ending conventions.