git ls-files - это довольно сложная команда с несколькими различными режимами, поэтому ответ на вопрос темы:
печатает файлы git ls-файлов в текущем рабочем каталоге
- и нет, и да.
Мне сказали, что git ls-файлы печатают файлы в текущем рабочем каталоге.
Иногда это так, а иногда нет. Как прокомментировал Кейт Томпсон , вам следует прочитать документацию - но Git документация отличается непроницаемостью, полным жаргоном и настолько неясна, что фальшивка Git справочные страницы трудно отличить от реальных.
Общая задача git ls-files состоит в том, чтобы иметь дело с файлами, которые находятся и / или отсутствуют в index . Индекс является сложной Git внутренней сущностью, которая Git навязывается всем пользователям. Само по себе оно настолько важно и / или неясно и / или плохо названо, что на самом деле имеет три имен в Git: Git иногда называет его index , но площадка в другое время. Третье имя, кеш , сегодня встречается не так часто, но вы все равно будете иногда его видеть.
В индексе много ролей, но его главное - то, которое вам следует знать всегда - это то, где вы (и Git) создаете следующий коммит, который вы намереваетесь сделать. Содержимое индекса состоит в основном из копий 1 файлов. Каждая из этих копий имеет имя - имя пути относительно верхнего уровня хранилища, такое как README.md или top/mid/file.ext - и некоторое содержимое: снимок файл. Также имеется бит режима , который для обычных файлов представляет собой всего один бит - он может принимать только одно из двух значений, но по разным причинам обозначается как 100644 для файла, который не является исполняемым или 100755 для исполняемого файла. 2
Существует также номер этапа , который обычно равен нулю. Вы можете увидеть все это в git ls-files --stage выводе:
$ git ls-files --stage
100644 c2f5fe385af1bbc161f6c010bdcf0048ab6671ed 0 .cirrus.yml
100644 c592dda681fecfaa6bf64fb3f539eafaf4123ed8 0 .clang-format
100644 42cdc4bbfb05934bb9c3ed2fe0e0d45212c32d7a 0 .editorconfig
100644 b08a1416d86012134f823fe51443f498f4911909 0 .gitattributes
(больше опущено).
Действие по умолчанию для git ls-files состоит в перечислении имен файлов, которые являются ( а) в индексе и (б) соответствуют текущему рабочему каталогу или его подкаталогу. Так что для файлов, которые находятся в текущем рабочем каталоге, и также находятся в индексе, git ls-files напечатает имена этих файлов. Для файлов, которые находятся в текущем рабочем каталоге, но в индексе которых нет , а не , git ls-files не будет печатать имена этих файлов:
Я создал новый файл HelloWorld.cs (и я не использовал git add для добавления этого файла) ...
Когда вы git checkout делаете коммит, Git заполняет индекс от , которые фиксируют. Таким образом, все файлы, которые являются в коммите, имеют копии в индексе; файлы, которые не в коммите, не делают. Поскольку файл HelloWorld.cs не был в коммите, его нет в индексе.
Вы создали файл, поэтому он теперь находится в вашем рабочем дереве или рабочее дерево . Здесь у вас есть файлы, которые вы можете видеть и работать с ними; эти файлы в обычном формате, а не в специальном Git -только формате, как в индексе. Но этот файл не в индексе.
Если вы запустите git add, это скажет Git: Скопируйте этот файл из рабочего дерева в индекс. Если он уже находится в индексе, этот процесс перезаписывает копию индекса. Если нет, то он создает новый файл в индексе. Но вы тоже этого не сделали.
, тогда я запускаю git ls-files, и он не отображал HelloWorld.cs.
Поскольку действие по умолчанию git ls-files для отображения имен файлов, которые являются в индексе, а HelloWorld.cs - , а не в индексе, git ls-files не будет отображать имя файла сейчас.
(Обратите внимание, что для git ls-files существуют другие режимы работы. В частности, git ls-files --other указывает программе перечислить файлы, которые являются в рабочем дереве, но не *1123* в указателе.)
1 Технически, то, что находится в индексе, это не копия файла, а скорее ссылка на объект Git blob . Но это имеет значение только в том случае, если вы начинаете заниматься операциями низкого уровня git ls-files --stage и git update-index. В основном, вы можете просто думать о том, что индекс содержит копии файлов, а не ссылки на копии.
2 Они напоминают биты режима Linux stat, потому что они на самом деле Linux stat биты режима. Часть 10000 - это режим S_IFREG. Ссылки Symboli c в индексе имеют режим 120000, который соответствует битам S_IFLNK. Git когда-то поддерживал дополнительные биты прав доступа, но это оказалось ошибкой, поэтому теперь разрешены только rw-r - r-- (644) и rwxr-xr-x (755). Записи Gitlink также появляются в индексе и имеют режим 160000, который не является допустимым режимом Linux файла. Каталоги никогда не появляются в индексе, поэтому Git не будет хранить каталоги, но режим 40000 появляется в дереве объектов.