Я встречал это утверждение в документации git: получение файла аналогично использованию git reset с указанием пути к файлу, за исключением того, что он обновляет рабочий каталог вместо стадии. Ссылка: https: // www ....

1
caffein 5 Мар 2021 в 00:50

1 ответ

Лучший ответ

Прежде всего, это не официальная документация, и, на мой взгляд, это тот случай, когда Atlassian очень поверхностно сравнивает две команды. Иногда, как в этот раз, одна и та же команда git выполняет очень разные операции в зависимости от того, какие параметры вы используете. На SO вы можете найти хорошие ответы, которые углубят тему.

Чтобы ответить на ваш вопрос, вот что говорится в официальной документации о git checkout с указанием пути:

Перезаписать содержимое файлов, соответствующих указанному пути. Когда <tree-ish> (чаще всего фиксация) не дается, перезаписываем рабочее дерево с содержанием в индексе. Когда дан <tree-ish>, перезаписать как индекс, так и рабочее дерево содержимым в <tree-ish>.

Вы находитесь во втором случае, когда задан <tree-ish> (HEAD), и это ожидаемое поведение: как индекс, так и рабочий каталог перезаписываются старой версией test.txt.

Вместо этого, если вы используете git checkout test.txt, а test.txt уже поставлен, ни рабочий каталог, ни индекс не меняются, потому что вы в основном заменяете версию рабочего каталога версией индекса, но они, очевидно, остаются теми же.

Статья Atlassian пытается сказать следующее:

  • git checkout <pathspec> в основном работает с рабочим каталогом (также с индексом, если предоставляется <tree-ish>)
  • git reset работает только с индексом.

Недоразумение возникло из-за того, что в git reset <tree-ish> по умолчанию равен HEAD. Вместо этого git checkout ведет себя по-другому, если вы укажете <tree-ish> или нет.

3
Marco Luzzara 4 Мар 2021 в 22:56