CODEWITHSUNDEEP
git
Bernard
Bernard

Reputation: 17301

Git clean not removing a file

git reset --hard HEAD

gives me 

git status

# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   "LIFE/uploads/docs/Community_Plan_onlineA\314\203\342\200\240%92.pdf"
nothing added to commit but untracked files present (use "git add" to track)

Now, usually doing a clean would get rid of this untracked file.

git clean -df

Removing "LIFE/uploads/docs/Community_Plan_onlineA\314\203\342\200\240%92.pdf"

I'm however gettings this

git status

# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   deleted:    "LIFE/uploads/docs/Community_Plan_online\303\203\342\200\240%92.pdf"
#
no changes added to commit (use "git add" and/or "git commit -a")

Note the slightly different file name (_Plan_online\303 instead of _Plan_onlineA\314). What is causing this file to stick? I'm pulling on OSX btw with core.autocrlf=false

Upvotes: 3

Views: 4079

Answers (1)

Bert F
Bert F

Reputation: 87603

Its not really stuck - you've got a tracked (commited) file with the name LIFE/uploads/docs/Community_Plan_online\303\203\342\200\240%92.pdf. Stage the deletion and commit it to get rid of it.

Git gets duped by case-insensitive filesystems sometimes. You're dealing with two filenames with two different Unicode characters that HFS+ considers to be case-equivalent. Git thinks they are different files under some conditions and sometimes thinks are the same file under other conditions.

The OS-X default filesystem is case-insensitive and it stores filenames in decomposed UTF-8 ("normalization form D" according to that answer). So I think the 'A\314' is HFS+ using decomposed UTF-8 for a Latin 'A' with a combining diacritical mark (reverse comma above?). The '\303' that Git is reporting represents a Latin A with a tilde. I'm guessing that those letters are considered equivalent on a case-insensitive filesystem.

During the first git status, I would guess that Git checks the status of all tracked files and HFS+ reports a case-equivalent filename as present for that filename. Then Git looks for untracked files and sees a filename that doesn't exactly match any filename in its list of tracked files. Thus Git reports just an untracked file.

During the second git status, Git checks the status of all tracked files and HFS+ reports no file matching the filename. Thus Git reports that a tracked file has been deleted. (Of course, now that the file is gone, it is not reported as a untracked file.)

You didn't say what version of Git you were using, but a newer version of Git may handle the situation better.

Upvotes: 2

Related Questions