From: Torsten Bögershausen Date: Thu, 13 Jul 2017 08:42:29 GMT Subject: Re: Git on macOS shows committed files as untracked Message-ID: <130b338b-2e77-65d6-a3fa-f272ac43b81c@web.de> In-Reply-To: <20170712231557.lu7ppj3bric2fahi@sigill.intra.peff.net> On 13/07/17 01:15, Jeff King wrote: > On Wed, Jul 12, 2017 at 06:21:28PM -0400, roeder.git@mailnull.com wrote: > >> In Git on macOS (git version 2.13.2 | brew install git) the status >> command will show folders as untracked even though they are committed >> and checked out from the repository. Does not reproduce on Windows and >> Ubuntu. >> [...] >> >> "d\314\207\316\271\314\223\314\200\342\225\223\316\265\357\256\257\360\222\221\217\342\227\213\342\225\223\320\243\314\213/" > > Probably the issue has to do with Unicode normalization, and you have > files in your repository that can't be represented on your filesystem. > For example, the first two code-points above are "d" followed by U+0307, > "COMBINING DOT ABOVE". That pair can also be represented as U+1E0B, > "LATIN SMALL LETTER D WITH DOT ABOVE". > > I don't recall which form HFS+ normalizes to, but basically what happens > is that Git opens the file with some name, and the filesystem quietly > rewrites that under the hood to a different, normalized name. Then when > Git walks the directory later to ask which files are present, it sees > this other filename that it has no clue about. > > Generally the solution is to commit the normalized name. There's some > logic inside Git to "precompose" names to the right normalization, but I > think that only affects new files you add. Existing committed files with > the wrong normalization run into this issue. > > -Peff > Thanks for the fast analyzes - in short: what does git -c core.precomposeunicode=true status say ? The easiest thing may be to set git config --global core.precomposeunicode true