Resolving Git Issues on Windows and Case Sensitivity

UTF-16LE-BOM, which is a common encoding on Windows: + ---- *.c working-tree-encoding=UTF-16LE-BOM ---- + You will need to run `git add --renormalize` to have this take effect. Note that if you are making these changes on a project that is used across platforms, you'll probably want to make it in a per-user configuration file or in the one in `$GIT_DIR/info/attributes`, since making it in a `.gitattributes` file in the repository will apply to all users of the repository. + See the following entry for information about normalizing line endings as well, and see linkgit:gitattributes[5] for more information about attribute files. [[windows-diff-control-m]] I'm on Windows and git diff shows my files as having a `^M` at the end.:: By default, Git expects files to be stored with Unix line endings. As such, the carriage return (`^M`) that is part of a Windows line ending is shown because it is considered to be trailing whitespace. Git defaults to showing trailing whitespace only on new lines, not existing ones. + You can store the files in the repository with Unix line endings and convert them automatically to your platform's line endings. To do that, set the configuration option `core.eol` to `native` and see <<recommended-storage-settings,the question on recommended storage settings>> for information about how to configure files as text or binary. + You can also control this behavior with the `core.whitespace` setting if you don't wish to remove the carriage returns from your line endings. [[always-modified-files-case]] Why do I have a file that's always modified?:: Internally, Git always stores file names as sequences of bytes and doesn't perform any encoding or case folding. However, Windows 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

This section addresses common Git issues on Windows, including encoding and line ending problems, and case sensitivity conflicts. It provides solutions such as configuring Git to use native line endings, controlling whitespace behavior, and removing files with conflicting case names to avoid perpetual modification issues. Additionally, it suggests adopting a naming convention to prevent future case conflicts.