Skip to content

Commit 087c616

Browse files
bk2204gitster
authored andcommitted
docs: explain how to deal with files that are always modified
Users frequently have problems where two filenames differ only in case, causing one of those files to show up consistently as being modified. Let's add a FAQ entry that explains how to deal with that. In addition, let's explain another common case where files are consistently modified, which is when files using a smudge or clean filter have not been run through that filter. Explain the way to fix this as well. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 409f066 commit 087c616

File tree

1 file changed

+33
-0
lines changed

1 file changed

+33
-0
lines changed

Documentation/gitfaq.txt

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -363,6 +363,39 @@ information about how to configure files as text or binary.
363363
You can also control this behavior with the `core.whitespace` setting if you
364364
don't wish to remove the carriage returns from your line endings.
365365

366+
[[always-modified-files-case]]
367+
Why do I have a file that's always modified?::
368+
Internally, Git always stores file names as sequences of bytes and doesn't
369+
perform any encoding or case folding. However, Windows and macOS by default
370+
both perform case folding on file names. As a result, it's possible to end up
371+
with multiple files or directories whose names differ only in case. Git can
372+
handle this just fine, but the file system can store only one of these files,
373+
so when Git reads the other file to see its contents, it looks modified.
374+
+
375+
It's best to remove one of the files such that you only have one file. You can
376+
do this with commands like the following (assuming two files `AFile.txt` and
377+
`afile.txt`) on an otherwise clean working tree:
378+
+
379+
----
380+
$ git rm --cached AFile.txt
381+
$ git commit -m 'Remove files conflicting in case'
382+
$ git checkout .
383+
----
384+
+
385+
This avoids touching the disk, but removes the additional file. Your project
386+
may prefer to adopt a naming convention, such as all-lowercase names, to avoid
387+
this problem from occurring again; such a convention can be checked using a
388+
`pre-receive` hook or as part of a continuous integration (CI) system.
389+
+
390+
It is also possible for perpetually modified files to occur on any platform if a
391+
smudge or clean filter is in use on your system but a file was previously
392+
committed without running the smudge or clean filter. To fix this, run the
393+
following on an otherwise clean working tree:
394+
+
395+
----
396+
$ git add --renormalize .
397+
----
398+
366399
[[recommended-storage-settings]]
367400
What's the recommended way to store files in Git?::
368401
While Git can store and handle any file of any type, there are some

0 commit comments

Comments
 (0)