相同的文件列为未追踪和删除 [英] Same files listed as both untracked and deleted

问题描述

 在Git仓库中运行 git status  >没有为commit提交更改：
（使用git add / rm< file> ...更新将提交的内容）
（使用git checkout  - < file> .. 。放弃工作目录中的更改）
 
删除：路径/到/ file1.sql 
删除：路径/到/ file2.sql 
删除：路径/到/ file3 .sql 
 
未经记录的文件：
（使用git add< file> ...来包含将要提交的内容）
 
 path / to / file1.sql 
 path / to / file2.sql 
 path / to / file3.sql 
 
没有更改添加到提交中（使用git add和/或git commit -a）
  

其他所有文件都可以。
我已经尝试过重置，结帐等操作，并再次克隆存储库（我们使用中央服务器）。没有任何东西可以解决问题，但仅限于使用Windows的特定用户。
这个问题在Linux上不会出现。

其他信息：

• git diff 显示没有输出。


• 我已经尝试设置 core.autocrlf 为false。
  

解决方案

它实际上是一件非常简单的事情：已经在文件名的 end 处提供了一个空格。
显然，Windows无法处理这个问题，并且每次都会自动删除空间（在克隆之后，结账等之后）。

所以Git显示正确的信息，文件path / to / file1.sql已被删除，文件path / to / file1.sql是新的（对不起，这没有显示在问题中，现在我已经纠正它显示示例Git输出中的空间）。

I一开始我没有注意到这一点，因为我简单地<目录 ls 目录 / path / to / 的内容Linux在看到 git status 后很好，并试图在Windows中调试所有内容（不可能，除非您通过选择Git输出的正确部分来注意空间） 。
我在执行额外的文件名检查（在Linux上），这要归功于吸血鬼的评论我获得了奇怪的结果

  ls /path/to/file1.sql 
 ls：找不到文件
  

按下TAB并看到/ path / to / file1.sql\我找到了它。
我认为这个问题相当微不足道，但是由于每天都不会有人在名称末尾使用空格提交文件，因此我认为可能需要一段时间才能发现问题并不存在Git。

因此，我现在要留下问题和答案，如果您不同意只是沮丧，我会删除所有内容。

感谢所有在评论中提供帮助的人。

Running git status in a Git repository, I get:

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:    path/to/file1.sql 
        deleted:    path/to/file2.sql 
        deleted:    path/to/file3.sql 

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        path/to/file1.sql
        path/to/file2.sql
        path/to/file3.sql

no changes added to commit (use "git add" and/or "git commit -a")

Every other file is fine. I already tried reset, checkout, etc., and also cloning the repository again (we use a centralized server). Nothing solves the issue, but only for a specific user using Windows. The problem does not appear on Linux.

Additional information:

• git diff shows no output.
• I've already tried setting core.autocrlf to false.

解决方案

It was actually a very simple thing: the files had been committed with a space at the end of the filename. Apparently Windows cannot handle this, and automatically removes the space every time (after clone, after checkout, etc.).

So Git shows the correct information, the file "path/to/file1.sql " has been deleted, and the file "path/to/file1.sql" is new (sorry this didn't show in the question, now that I now I corrected it to show the space in the sample Git output).

I couldn't notice this at first, because I simply lsed the content of the directory /path/to/ on Linux after seeing that git status was fine there, and tried to debug everything in Windows (not possible, unless you somehow notice that space by selecting the right part of the Git output). While I was performing an additional check on the filenames (on Linux) thanks to Vampire's comment I obtained the strange result

ls /path/to/file1.sql
ls: file not found

After pressing TAB and seeing "/path/to/file1.sql\ " I figured it out. I think the problem is quite trivial, but since it doesn't happen everyday that someone commits files with a space at the end of the name, I think it can take a while to figure out there is no real problem with Git.

So I'm going to leave the question and the answer for now, if you disagree just downvote and I'll delete everything.

Thanks to everyone who helped in the comments.

这篇关于相同的文件列为未追踪和删除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！