git ls-files --stage показывает файлы даже после фиксации - PullRequest
1 голос
/ 12 марта 2020

Я после git команда, которая показывает все файлы, в настоящее время находящиеся в промежуточной области (это же как индекс?).

Сначала я удалил все файлы из индекса:

$ git rm --cached *
rm 'newfile'
rm 'os-list.txt'
rm 'remote_stuff'
rm 'removethis'

Теперь я проверяю файлы в индексе:

$ git ls-files --stage
100644 07e6e472cc75fafa944e2a6d4b0f101bc476c060 0       .gitignore

Вы видите только файл .gitignore.

Затем мы изменяем содержимое нового файла. Затем мы добавляем новый файл в индекс.

$ git add newfile

Проверьте статус:

$ git status -s
M  newfile
D  os-list.txt
D  remote_stuff
D  removethis
?? os-list.txt
?? remote_stuff
?? removethis

Мы можем видеть, что новый файл теперь находится в индексе.

Теперь мы ожидаем, что область подготовки быть пустым, когда мы фиксируем файлы.

$ git commit -m "TEST333"
[master 0adab53] TEST333
 4 files changed, 1 insertion(+), 13 deletions(-)
 delete mode 100644 os-list.txt
 delete mode 100644 remote_stuff
 delete mode 100644 removethis

Но даже после фиксации мы видим, что newfile все еще находится в промежуточной области:

$ git ls-files --stage
100644 07e6e472cc75fafa944e2a6d4b0f101bc476c060 0       .gitignore
100644 76abab2928bdd7dfe157109666023bb0c5e4c465 0       newfile

Но если мы проверяем статус, мы видим, что в промежуточной стадии ничего нет area:

$ git status -s
?? os-list.txt
?? remote_stuff
?? removethis

Что мне нужно, так это команда показать все файлы в промежуточной области. Команда git ls-files --stage возвращает вывод, который я не понимаю.

Спасибо!

1 Ответ

2 голосов
/ 12 марта 2020

Теперь мы ожидаем, что область размещения будет пустой, когда мы фиксируем файлы.

Это ваша ошибка. Не ожидайте этого!

... если мы проверим статус, то увидим, что в области подготовки ничего нет

git status не показывает, что находится в индексе / плацдарм. Вместо этого для каждого файла сравнивает то, что находится в области индекса / размещения, с:

  • , что находится в коммите HEAD: если он отличается, файл "ставится для совершить "; и
  • что находится в рабочем дереве: если файл отличается, файл «не подготовлен для фиксации»

- поэтому файл может быть оба"подготовлено для фиксации" и"не подготовлено для фиксации". Это означает, что копия index , которую вы видите с git ls-files --stage, отличается от обеих двух других копий .

Каждый файл имеет три активные копии . 1 Когда все три одинаковы , git status ничего не говорит. Если некоторые копии файла F отличаются, git status сообщает вам о файле F . Вот и все, что здесь есть на самом деле.

Индекс / область подготовки всегда содержит 2 того, что вы планируете (или Git планы) поместить в свой следующий коммит. Вот почему вы должны обновить его после изменения копии рабочего дерева: чтобы то, что Git планирует добавить в следующий коммит, соответствовало копии рабочего дерева.


1 Технически, это до трех копий, так как вы можете пропустить одну или две копии. Файл отслеживается тогда и только тогда, когда в индексе есть его копия (даже если он находится в коммите HEAD, он отслеживается только в том случае, если он также в индексе) , Файл рабочего дерева не отслеживается , если он существует и отсутствует в индексе. (Следовательно, после git rm --cached файл, который находится в HEAD и в рабочем дереве, одновременно подлежит удалению и не отслеживается.)

2 См. Сноску 1, а затем посмотрите конфликтующий случай слияния. Во время конфликтующего слияния индекс содержит до трех копий каждого файла: базовая копия слияния, копия --ours и копия --theirs. Если вы добавляете копию HEAD и копию рабочего дерева, это означает, что во время конфликтующих слияний в одном файле может быть до пяти активных копий.

...