git clean不删除文件 [英] Git clean not removing a file

问题描述

git reset --hard HEAD

给我

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"

但是我得到了

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")

请注意稍有不同的文件名(_Plan_online \ 303而不是_Plan_onlineA \ 314).是什么导致此文件卡住?我正在用core.autocrlf = false

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

推荐答案

它并没有真正卡住-您有一个名为 LIFE/uploads/docs/Community_Plan_online \ 303 \ 203 \的跟踪(提交)文件.342 \ 200 \ 240％92.pdf .分阶段删除并提交以删除它.

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有时会被不区分大小写的文件系统所欺骗.您正在处理带有两个不同Unicode字符的两个文件名，HFS +认为这两个文件名是大小写等效的.Git认为在某些情况下它们是不同的文件，有时在其他情况下则认为它们是同一文件.

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.

OS-X默认文件系统不区分大小写，并且将文件名存储在已分解的UTF-8 中(规范化表格D"(根据该答案).因此，我认为'A \ 314'是HFS +，对带有组合变音符号的拉丁文'A'使用分解后的UTF-8(上面的反逗号?).Git报告的"\ 303"表示带有波浪号的拉丁字母A.我猜这些字母在不区分大小写的文件系统上被认为是等效的.

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.

在第一个git状态期间，我猜想Git会检查所有跟踪文件的状态，而HFS +会报告该文件名存在的大小写等效文件名.然后，Git查找未跟踪的文件，并看到与其跟踪文件列表中的任何文件名都不完全匹配的文件名.因此，Git仅报告未跟踪的文件.

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.

在第二个git状态期间，Git检查所有跟踪文件的状态，并且HFS +报告没有与文件名匹配的文件.因此，Git报告跟踪文件已被删除.(当然，既然文件不见了，就不会报告为未跟踪文件.)

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.)

您没有说您使用的是哪个版本的Git，但是较新的Git版本可能会更好地处理这种情况.

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

这篇关于git clean不删除文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！