未跟蹤的文件未顯示在 git status 中

Question

我有一個具有以下文件夾結構的項目：

所有項目文件都在 base_fldr 文件夾中。 此外，我在 base_fldr 中有幾個文件夾，名為 sub_fldr1 和 sub_fldr2。 這些子文件夾還包含一些文件。

如果我修改了 base_fldr 或 base_fldr\\sub_fldr\\ 中的任何文件，則 git status 會將它們顯示為已修改。 此外，如果我向 base_fldr 添加新文件，git status 會將其顯示為未跟蹤文件。

我的問題是，如果我在 base_fldr\\sub_fldr\\ 中添加一個新文件，那么 git status 不會將該文件顯示為未跟蹤。 它甚至不會提供有關該文件的任何信息。

該文件或其擴展名不在我的 .gitignore 列表中。 我也試過 git add sub_fldr\\file_name 但它既沒有給出錯誤也沒有將文件添加到 index.html 。

知道這里發生了什么嗎？ 謝謝！

Answer 1

我弄清楚出了什么問題。 基本上我的 .gitignore 文件中的第一行是“*/”。 這會導致 git status 命令忽略添加到子目錄的任何文件。 但有趣的是，如果我修改子文件夾中的任何文件，git status 會正確地將它們顯示為已修改，因為文件已經在 git 存儲庫中，但忽略了子文件夾中的新文件。

我通過刪除 .gitignore 文件中的行來解決我的問題，以不忽略子文件夾中的更改，然后將新文件添加到索引，然后再次添加回 .gitignore 中的行，以便它忽略子文件夾中生成的任何文件。

感謝大家的回應。

Answer 2

我遇到了丟失跟蹤文件的類似問題。 在嘗試管理跟蹤文件的本地修改版本而不必經常避免意外提交的方法時，我運行了以下命令：

git update-index --assume-unchanged my-tracked-file-that-is-awol

我最終放棄了這個想法，但忘記撤消該命令，因此對這個文件和其他 --assume-unchanged 文件的后續更改完全缺失：

git status -u --ignored

我花了一段時間才弄清楚發生了什么，但我只需要使用以下命令來反轉命令：

git update-index --no-assume-unchanged my-tracked-file-that-is-awol

Answer 3

這可能是因為您的 base_fldr\\sub_fldr\\ 目錄未被跟蹤，如果您運行：

git add base_fldr\sub_fldr\

從您的工作副本根目錄中，它會自動添加該目錄以及該目錄中的其他文件和目錄。

默認情況下，git 不會顯示未跟蹤目錄中的文件。

Answer 4

你的sub_fldr目錄中有.git子目錄嗎？ Git 可能認為您正在嘗試使用submodules 。

Answer 5

為了調試這樣的問題，請通過觀察以下兩個輸出來查看您的.gitignore文件是否是罪魁禍首

請參閱https://git-scm.com/docs/git-ls-files

1. git ls-files --other --directory --exclude-standard

這將顯示所有未跟蹤的文件，同時遵守.gitignore文件。

2. git ls-files --other --directory

這將顯示所有未跟蹤的文件，而不遵守.gitignore文件。

無論哪個文件存在於2輸出中，但不存在於1輸出中，都不會顯示在 untracked 中，因為.gitignore文件中有一些標志

Answer 6

這是此問題中描述的行為的另一個原因（git status 未跟蹤文件列表不包括子文件夾中的未跟蹤文件）。 如果該文件由於子文件夾中的 .gitignore 文件而未跟蹤，則該文件將不會包含在 git status 未跟蹤文件列表中。

Answer 7

自 2011 年以來，這在 Git v1.8.3-rc0（2013 年 4 月）中首次得到修復。
它修復了代碼中的一些問題，以遍歷工作樹以查找未跟蹤和/或忽略的文件，清理和優化代碼路徑。

見提交0aaf62b ， 提交defd7c7 ， 提交8aaf8d7 ， 提交b07bc8c ， 提交95c6f27 ， 提交6cd5c58 ， 提交46aa2f9 ， 提交5bd8e2d ， 提交be8a84c ， 提交c94ab01 ， 提交184d2a8 ， 提交0104c9e ， 提交289ff55 ， 提交560bb7a由（2013年4月15日）卡斯滕Blees ( kblees ) 。
^{（由Junio C gitster合並gitster 提交 7093d2c ，2013 年 4 月 23 日）}

dir.c : 使 'git-status --ignored' 在前導目錄中工作

^{簽字人： Karsten Blees}

“ git status --ignored path/ ”不“名單中忽略的文件和目錄path ”如果“的一些組件path ”被列為未跟蹤。

在遍歷前導目錄時禁用DIR_SHOW_OTHER_DIRECTORIES標志。 這可以防止帶有DIR_SHOW_IGNORED標志的treat_leading_path()在頂級未跟蹤目錄中止。

作為副作用，這也消除了每個前導目錄級別的遞歸目錄掃描，因為從treat_directory()調用時read_directory_recursive()不能再調用treat_leading_path() 。

---

但是，6 年后（2019 年末），在 Git 2.25（2020 年第一季度）中，對目錄遍歷 API 進行了各種修復……恢復上面看到的那個修復，並重新實現它。

請參閱Junio C gitster ( gitster ) 的commit 6836d2f （2019 年 12 月 20 日） 。
參見commit c847dfa 、 commit 777b420 、 commit b9670c1 （2019 年 12 月 19 日）和commit c5c4edd 、 commit 072a231 、 commit 2f5d384 、 commit a2b1336 、 commit 452efd1 （2019 年 12 月19 newren ）（ 2019 年 12 月19 newren ）
^{（由Junio C gitster合並-- gitster --在d2189a7 提交中，2019 年 12 月 25 日）}

Revert "dir.c : 使 ' git-status --ignored ' 在前導目錄中工作”

^{簽字人： Elijah Newren}

提交be8a84c52669 (" [ dir.c ](https ): make ' git-status --ignored '-04 在領先的目錄中工作15，Git的v1.8.3-RC0 - 合並）指出，

 git status --ignored <SOMEPATH>

如果<SOMEPATH>未被跟蹤，則不會在<SOMEPATH>列出被忽略的文件和目錄，並修改行為以使其顯示它們。

然而，它是通過破壞一致性的黑客實現的。 它會在<SOMEPATH>下顯示與簡單路徑不同的路徑

git status --ignored | grep <SOMEPATH>

會給他們看。

正確的修復稍微復雜一些，並且由於這個 hack 稍微復雜，所以我們恢復這個提交（但保留測試用例的更正版本），稍后將使用后續補丁修復原始錯誤。

一些歷史可能會有所幫助：

在提交 48ffef966c76 （“ ls-files : fix overeager pathspec optimization”, 2010-01-08, Git v1.7.0-rc0 -- merge ）中提出了與我們正在恢復的提交非常相似的情況； 但它實際上朝着相反的方向發展。

在那個提交中，它提到了如何

git ls-files -o --exclude-standard t/

用於在t/下顯示未跟蹤的文件，即使t/被忽略，然后更改行為以停止在被忽略的目錄下顯示未跟蹤的文件。

更重要的是，此提交考慮保留此行為，但指出當指定多個路徑規范並因此拒絕它時，它會與行為不一致。

當指定一個路徑規范與零或兩個路徑規范時，整個不一致的原因是因為路徑規范的公共前綴是通過一組不同的檢查（在treat_leading_path() ）而不是正常的文件/目錄遍歷（通過read_directory_recursive()和treat_path() )。

因此，為了一致性，需要檢查兩個代碼路徑是否產生相同的結果。

還原提交 be8a84c526691667fc04a8241d93a3de1de298ab ，除了刪除它添加的測試用例之外，修改它以檢查正確和一致的行為。

和：

dir : 修復對公共前綴目錄的檢查

^{簽字人： Elijah Newren}

許多年前，目錄遍歷邏輯有一個優化，它總是遞歸到所有路徑規范的公共前綴的任何目錄中，而無需遍歷前導目錄以到達所需目錄。

因此，

 git ls-files -o .git/ # case A

會注意到.git/是所有路徑規范的公共前綴（因為它是唯一列出的路徑規范），然后遍歷它並開始顯示該目錄下的未知文件。

不幸的是， .git/不是我們應該遍歷的目錄，這使得這個優化有問題。

這也影響了以下情況：

 git ls-files -o --exclude-standard t/ # case B

其中t/在.gitignore文件中，因此不有趣，不應遞歸。

它還影響了以下情況：

 git ls-files -o --directory untracked_dir/ # case C

其中untracked_dir/確實未被跟蹤，因此很有趣，但--directory標志意味着我們只想顯示目錄本身，而不是遞歸到它並開始在它下面列出未跟蹤的文件。

B 類錯誤在提交16e2cfa90993 ("read_directory() ：進一步拆分treat_path() ”，2010-01-08）和48ffef966c76 （“ ls-files ：修復過度的路徑規范優化”，2010-01- 08, Git v1.7.0-rc0 -- merge ），其想法是我們首先想檢查公共前綴是否有趣。

前者補丁指出， treat_path()檢查公共前綴時，因為不能使用treat_path()需要dir_entry()我們沒有看過在點任何目錄我們正在檢查常見的前綴。

因此，該補丁將treat_one_path()從treat_path()分離出來。

然后，后一個補丁創建了一個新的treat_leading_path() ，它手動復制了treat_path()中無法分解的部分，然后為其余部分調用treat_one_path() 。

這種方法存在三個問題：

• treat_leading_path()的重復邏輯不小心錯過了對特殊路徑的檢查（例如is_dot_or_dotdot和匹配的“ .git ”），導致 case A 類型的錯誤繼續成為問題。
• treat_leading_path()邏輯假設我們應該遍歷 path_treatment 不是 path_none 的任何地方，即它使 C 類錯誤永久存在。
• 這意味着我們有需要保持同步的拆分邏輯，冒着人們引入新不一致的風險（例如在提交 be8a84c52669 中，我們在本系列的前面恢復了，或者在提交 df5bcdf83ae 中，我們將在后續提交中修復）

通過使treat_leading_path()不僅在每個前導路徑組件上循環，而且在每個組件上直接調用treat_path()解決大多數這些問題。

為此，我們必須創建一個合成的dir_entry,但這只需幾行。

然后，講究path_treatment結果，我們從得到treat_path()和不善待path_excluded, path_untracked,並path_recurse都一樣path_recurse 。