2013-04-04 106 views
3
git reset --hard HEAD 

給我Git的乾淨不刪除文件

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) 

現在,一般做一個乾淨就會改掉這個未跟蹤文件。

git clean -df 

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

我不過gettings這

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)。 什麼是導致此文件粘滯?我拉OSX btw與core.autocrlf = false

回答

2

它並沒有真正卡住 - 你有一個名爲LIFE/uploads/docs/Community_Plan_online\303\203\342\200\240%92.pdf的跟蹤(提交)的文件。階段刪除並提交它來擺脫它。

有時Git會被大小寫不敏感的文件系統欺騙。您正在處理兩個具有兩個不同Unicode字符的文件名,HFS +認爲這些文件名與大小寫相同。 Git認爲它們在某些條件下是不同的文件,有時認爲在其他條件下是相同的文件。

OS-X默認文件系統不區分大小寫,它存儲文件名decomposed UTF-8(根據該答案「歸一化表單D」)。所以我認爲'A \ 314'是HFS +對於拉丁文'A'使用分解的UTF-8並結合了變音符(上面的反向逗號)。 Git報告的'\ 303'代表帶有代字號的拉丁文A.我猜這些字母在不區分大小寫的文件系統上被認爲是等價的。

在第一個git狀態期間,我猜Git會檢查所有跟蹤文件的狀態,並且HFS +報告與該文件名相同的文件類型的文件名。然後Git查找未跟蹤的文件並查看與其跟蹤文件列表中的任何文件名不完全匹配的文件名。因此Git只報告未跟蹤的文件。

在第二個git狀態期間,Git檢查所有跟蹤文件的狀態,並且HFS +報告沒有匹配文件名的文件。因此Git報告一個被跟蹤的文件已被刪除。 (當然,現在文件已經不存在了,它不會被報告爲未跟蹤的文件。)

你沒有說你使用的是什麼版本的Git,但是更新版本的Git可以更好地處理這種情況。

+1

感謝您的解釋。我預計它必須處理文件名編碼,但你真的提供了一個很好的問題描述。我們正在混合的Windows/Mac環境中工作,所以我懷疑該文件是從Windows推入的。順便說一句,這個問題仍然存在於最新的git 1.8.2版本中。 – Alkaline 2013-04-06 07:48:17

+0

歡迎您@Alkaline - 酷用戶名。 – 2013-04-06 16:33:58