История коммитов не появляется, запустив "git log"

Question

Это относится к вопросу, заданному в git-commit-history-lost , и внесенные предложения помогли мне решить проблему, когда один из коммитов не появлялся в локальной системе, а в битовой корзине. , этот коммит появлялся

Я последовал предложению и смог извлечь историю коммитов с отсутствующей информацией о коммитах в локальном.

Я хотел бы спросить, что случилось, что коммит не появляется при выполнении команды git log в локальной сети?

Также было бы интересно узнать, что выполняет эта команда git log --follow -p -- <file name>.

Как мы можем избежать таких проблем в будущем, чтобы мы могли получить историю каждого коммита, выполнив git log

Answer 1

Если вы хотите просмотреть удаленные журналы, сначала локальная должна иметь копию удаленного индекса. Выполните git fetch, это поможет git понять, что необходимо обновить в локальной сети по отношению к удаленной.

Теперь выполните git log --all. Здесь отображаются все журналы всех ветвей.

ПРИМЕЧАНИЕ: Если вы не сделали git fetch, ваш локальный компьютер не будет знать, что было обновлено в удаленных ветвях.

git log показывает только текущие обновления локальной ветки.

git log не проверяет, что находится в удаленном репозитории.

Но git log --all показывает историю всех веток.

Чтобы понять, что такое локальные и удаленные ветви git bash различает все green, окрашенные как локальные ветви, и red, окрашенные как удаленные ветви, это может измениться для других терминалов bash.

Answer 2

Справочная страница (или документация git) - ваш друг:

    --follow
        Continue listing the history of a file beyond renames (works only for a single file).

    -p, -u, --patch
        Generate patch (see section on generating patches).

Так что, скорее всего, если вы уверены, что коммит находится в ветке, которую вы просматривали, и что она не была нисходящей, он находится ПОСЛЕ точки, в которой вы начали просматривать ветку (что может произойти, если вы ' находясь в отдельном режиме, проверяя определенный коммит в данный момент), ваш файл был когда-то переименован в или удален / воссоздан позже.

Git работает со «снимками», что означает, что каждый раз, когда вы фиксируете, git фактически сохраняет полное состояние вашего рабочего каталога, независимо от любого другого коммита, даже родительского. Это достигается путем сохранения полного списка файлов в объекте дерева, который, в свою очередь, указывает на объекты, содержащие содержимое файла (эти объекты оказываются одинаковыми при каждом коммите, если они не изменяются, поэтому дублированные данные не сохраняются, что подразумевает отсутствие потерь пространство).

Это позволяет Git очень эффективно сравнивать вещи, что делает разграничение двух случайных коммитов действительно простым, даже если они совершенно не связаны. На самом деле, Git просто не нужно помнить историю события. Ветви материализуются тем фактом, что каждый коммит ссылается на своего родителя (ей), точно так же, как связанный список.

Недостатком этого является то, что корреляция между двумя версиями одного данного файла основана на его имени файла . Если это имя файла меняется, это нарушает происхождение его собственной истории.

К счастью, git знает об этом и обладает многими эвристиками, позволяющими ему вернуться к своим ногам. Например, если он обнаружит, в пределах одного коммита, как удаление файла, так и создание нового файла с точно таким же содержимым, то git будет считать, что это переименование файла, даже если пользователь действительно удалил, а затем заново создал файл , В любом случае, независимо от git и строгой точки зрения файловой системы, обе эти операции были бы полностью эквивалентны (нам не нужны иноды и т. Д.).

Если вы делаете это с помощью обычных команд оболочки, Git сможет справиться с этим, но всегда полезно использовать для этого специальные команды git, например:

git mv <oldfilename> <newfilename>

… потому что это дает ему возможность предоставить дополнительную информацию, если он думает, что некоторые подсказки будут потеряны в этой операции. В противном случае все это остается ограниченным. Давайте предположим, что вы удалили файл, затем воссоздали ДВА других файлов с таким же содержимым, тогда ничто не говорит Git, какой файл переименован, а какой новый.

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