git rebase без изменения временных меток фиксации



имеет ли смысл выполнять git rebase при сохранении временных меток фиксации?



Я считаю, что следствием будет то, что новая ветвь не обязательно будет иметь даты фиксации хронологически. Это что теоретически возможно ли вообще? (например, используя команды сантехники; просто любопытно здесь)



если это теоретически возможно, то можно ли на практике с помощью rebase не менять временные метки?



например, предположим, что у меня есть следующее дерево:



master <jun 2010>
|
:
:
: oldbranch <feb 1984>
: /
oldcommit <jan 1984>


теперь, если я перебазироваться oldbranch on master, дата фиксации изменяется с февраля 1984 года по июнь 2010 года. Можно ли изменить это поведение так, чтобы временная метка фиксации не изменялась? В конце концов я бы таким образом получил:



      oldbranch <feb 1984>
/
master <jun 2010>
|
:


будет ли это вообще иметь смысл? Разрешено ли даже в git иметь историю, где старый коммит имеет более поздний коммит в качестве родителя?

651   4  

4 ответов:

Обновление Июнь 2014:Дэвид Фрейзер упоминает в комментариях решение также описано в "изменение временных меток при перезагрузке ветви git", используя опцию --committer-date-is-author-date (введено первоначально в январе. 2009 года в commit 3f01ad6

отметим, что --committer-date-is-author-date опция, похоже, оставляет временную метку автора и устанавливает временную метку фиксатора такой же, как и исходная временная метка автора, что и OP Olivier Verdier хотел.

я нашел последний коммит с правильной датой и сделал:

git rebase --committer-date-is-author-date SHA

посмотреть git am:

--committer-date-is-author-date

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


(оригинальный ответ, июнь 2012)

вы могли бы попробовать, для неинтерактивном rebase

git rebase --ignore-date

(от так что ответ)

это передается в git am, в которой говорится:

 --ignore-date

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

на git rebase, этот параметр " несовместим с параметром --interactive."

С вы можете изменить по желанию отметку времени старой даты фиксацииgit filter-branch), я полагаю, вы можете организовать свою историю Git с любым порядком даты фиксации, который вам нужен/нужен, даже установить будущее!.


как Оливье упоминает в своем вопросе,автор дата никогда не изменяется путем перебазирования;
Из Pro Git Book:

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

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

чтобы быть более ясным, в этом случае, как комментирует Оливье:

the --ignore-date делает противоположное тому, что я пытался достичь!
А именно, он стирает временную метку автора и заменяет их временными метками фиксации!
Поэтому правильный ответ на мой вопрос:
Ничего не делайте, так как git rebase на самом деле не изменяет временные метки авторов по умолчанию.


Если вы уже испортили даты фиксации (возможно, с перебазированием) и хотите сбросить их до соответствующих дат автора, вы можете запустить:

git filter-branch --env-filter 'GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE; export GIT_COMMITTER_DATE'

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

ответ заключается в том, что rebase на самом деле не меняет временные метки автора (вам не нужно ничего для этого делать), что меня вполне устраивает.

по умолчанию git rebase установит временную метку коммиттера на время, когда новая фиксация создается, но сохраняет временную метку автора нетронутой. Большая часть времени, это желаемое поведение, но в некоторых сценариях мы не хотим меняться отметка времени коммитера тоже. Как мы можем это сделать? Ну вот трюк я обычно делаю.

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

перед перебазированием запишите временную метку коммиттера, временную метку автора и сообщение фиксации всех коммитов, которые будут перебазированы в файл.

#NOTE: BASE is the commit where your rebase begins
git log --pretty='%ct %at %s' BASE..HEAD > hashlog

затем, пусть фактическая перебазировка состоится.

наконец, мы заменяем временную метку текущего фиксатора на ту, которая записана в файле, если сообщение фиксации совпадает с помощью git filter-branch.

 git filter-branch --env-filter '__date=$(__log=$(git log -1 --pretty="%at %s" $GIT_COMMIT); grep -m 1 "$__log" ../../hashlog | cut -d" " -f1); test -n "$__date" && export GIT_COMMITTER_DATE=$__date || cat'

если что-то пойдет не так, просто оформить заказ git reflog и все refs/original/ РЭС.

Furthormore, вы можете сделать то же самое с отметкой времени автора.

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

git log --pretty='%at %s' COMMIT1..COMMIT2 > hashlog
join -1 1 -2 1 <(cat hashlog | cut -f 1 | sort -nr | awk '{ print NR" " }') <(cat hashlog | awk '{ print NR" " }') | cut -d" " -f2,4- > hashlog_
mv hashlog_ hashlog
git filter-branch --env-filter '__date=$(__log=$(git log -1 --pretty="%s" $GIT_COMMIT); grep -m 1 "$__log" ../../hashlog | cut -d" " -f1); test -n "$__date" && export GIT_AUTHOR_DATE=$__date || cat'

Comments

    Ничего не найдено.