Я отредактировал старое сообщение о коммите, но журнал git показывает отредактированный коммит с более старой датой, чем коммиты, созданные совсем недавно - PullRequest
1 голос
/ 08 октября 2019

Я отредактировал сообщение о коммите, запустив git rebase -i <commit-yesterday> и выбрав опцию reword для перебазирования. После этого я запустил push --force, чтобы опубликовать изменения в удаленном хранилище. Я ожидаю, что когда я запускаю git log, я вижу список, подобный следующему:

commit 11111111
Date: Today 16:00:00
Message: The commit created Today at 16:00:00

commit 22222222
Date: Today 14:00:00
Message: The commit created Today at 14:00:00

commit 33333333
Date: Today 10:00:00
Message: The commit created Today at 10:00:00

commit 44444444
Date: Yesterday 15:00:00
Message: The message of this commit updated Today at 17:00:00 while it was created yesterday at 15:00:00

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

commit 55555555
Date: Yesterday 15:00:00
Message: The message of this commit updated Today at 17:00:00 while it was created yesterday at 15:00:00

commit 11111111
Date: Today 16:00:00
Message: The commit created Today at 16:00:00

commit 22222222
Date: Today 14:00:00
Message: The commit created Today at 14:00:00

commit 33333333
Date: Today 10:00:00
Message: The commit created Today at 10:00:00

commit 44444444
Date: Yesterday 15:00:00
Message: The commit created Yesterday at 15:00:00

Ответы [ 3 ]

2 голосов
/ 08 октября 2019

Каждый коммит имеет две отметки даты и времени, а не только одну. Одна временная метка предназначена для автора , а другая - для коммиттера . В новом коммите, который вы только что сделали с нуля, Git устанавливает одинаковые автора и коммиттера, а две метки времени - одинаковыми. Копирование коммита, однако, приводит к новому коммиттеру (вам и сейчас) при сохранении оригинального коммита автора и меток времени автора, по крайней мере по умолчанию.

Когда вы используете git rebase или git commit --amend, чтобы «изменить» коммит, вы на самом деле не изменяете исходный коммит. Вы не можете - ничто не может;даже сам Git не может изменить исходный коммит - поэтому вместо этого вы получаете новый коммит с новым идентификатором хеша, уникальным для нового коммита. Старый идентификатор хэша все еще действителен и все еще ссылается на старый коммит. Если старый коммит становится недостижимым , 1 , он со временем истечет и старый коммит действительно исчезнет, ​​но Git изо всех сил старается держать его как минимум месяц или около того, вна случай, если вы передумаете об этом и захотите его вернуть.

То, что вы здесь не показываете, это как вы работаете git log. То, что Git не показывает здесь - потому что вы не просили об этом - является базовым графом коммитов . Git - это коммиты, а сами коммиты образуют направленный ациклический граф или DAG. Многие команды и программы просмотра Git действительно должны показывать вам график, потому что этот график очень важен. Команда git log может показать вам график, но вы должны попросить его:

git log --graph

или мой любимый:

git log --all --decorate --oneline --graph

См. Красивые графы веток git и, в частности, этот ответ .

Чтобы Git показал вам обе отметки даты и времени, добавьте --pretty=fullerи пропустите --oneline, например:

git log --all --decorate --graph --pretty=fuller

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

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


1 Это технический термин с довольно длинным определением. Посетите веб-сайт Думайте как (а) Git , чтобы начать работу с этим.

0 голосов
/ 12 октября 2019

Я нашел магию git log. Поскольку я перебазировал коммит, его Дата коммита была изменена, но Дата автора никогда не меняется. Однако команда git log сортирует коммиты на основе Дата коммита (в порядке убывания), но показывает Дата автора коммитов. Это вызвало путаницу. Чтобы отобразить и дату фиксации, и дату автора, используйте параметр --pretty=fuller. Другими словами, выполнение следующей команды проясняет все:

git log --pretty=fuller

Обычно, Дата фиксации и Дата автора совпадают, но git rebase, git commit --amend, и cherry-pick - общие случаи, когда CommitДата отличается от даты автора для коммита.

0 голосов
/ 08 октября 2019

git rebase -i 44444444 покажет коммиты от 44444444 без включения 44444444. И все коммиты из коммитов, которые вы редактировали, теперь будут иметь новые хэши. В вашем случае вы увидите, что последний хеш коммита также обновлен.

Редактировать: я перезапустил ваш сценарий и посмотрю результат, как вы ожидаете.

git-test - master ❯ git log --oneline -n 6
78eb09a (HEAD -> master) 222222
6ec4cc9 33333
58d9aea 444444 first message
fc9cae1 oldest


git-test - master ❯ git rebase -i fc9cae1
[detached HEAD 19328bf] 444444 modified message
 Date: Tue Oct 8 14:54:27 2019 +0530
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 b
Successfully rebased and updated refs/heads/master.


git-test - master ❯ git log --oneline -n 6
82b30ed (HEAD -> master) 222222
34c1948 33333
19328bf 444444 modified message
fc9cae1 oldest
...