git rebase без зміни часових позначок фіксації

Чи було б доцільно виконувати git rebase, зберігаючи часові позначки фіксації?

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

Якщо це теоретично можливо, то чи можливо на практиці з базою даних не змінювати часові позначки?

Наприклад, припустимо, у мене є таке дерево:

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

Тепер, якщо я перебазуватися oldbranchна master, дата фіксації змін з лютого 1984 по червень 2010 Чи можна змінити цю поведінку так , що фіксація мітки часу не змінюється? Зрештою, я отримав би таким чином:

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

Це взагалі має сенс? Чи дозволяється навіть у git мати історію, коли стара фіксація має більш пізню версію як батьків?

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

Зауважте, що --committer-date-is-author-dateваріант, здається, залишає авторську часову марку та встановлює часову позначку читця, що відповідає оригінальній авторській часовій позначці, чого і хотів ОП Олів'є Верд'є .

Я знайшов останню прихильність із правильною датою і зробив:

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цей параметр "Не сумісний із - інтерактивним варіантом".

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

Як згадує Олів'є у своєму питанні, дата автора ніколи не змінюється за допомогою рефералу;
З книги Pro Git :

• Автор - людина, яка спочатку написала твір,
• тоді як виконавцем є особа, яка востаннє застосувала цю роботу.

Отже, якщо ви надсилаєте патч до проекту, і один із основних учасників застосовує патч, ви обидва отримуєте кредит.

Щоб бути надзвичайно зрозумілим, в цьому випадку, як коментує Олів'є:

це --ignore-dateробить протилежне тому, що я намагався досягти !
А саме, вона стирає авторську мітку часу та замінює їх часовими позначками.
Тож правильна відповідь на моє запитання:
Не робіть нічого, оскільки git rebase насправді не змінюють часові позначки авторів за замовчуванням.

Якщо ви вже накрутили дати фіксації (можливо, з перезавантаженням) і хочете відновити їх до відповідних авторських дат, можете запустити:

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

Важливе питання Фон С допомогло мені зрозуміти, що відбувається: коли ваша база даних, часова мітка комітента змінюється, але не часова мітка автора , що раптом все має сенс. Тож моє запитання насправді було недостатньо точним.

Відповідь полягає в тому, що база даних насправді не змінює часові позначки автора (для цього не потрібно нічого робити), що мені ідеально підходить.

За замовчуванням 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/знижки.

Фурторморе, ви можете зробити аналогічну до авторської мітки часу.

Наприклад, якщо відмітка часу автора деяких комісій вийшла з ладу, і не переставляючи ці комірки, ми просто хочемо, щоб авторська мітка часу відображалася в порядку, тоді допоможуть наступні команди.

git log --pretty='%at %s' COMMIT1..COMMIT2 > hashlog
join -1 1 -2 1 <(cat hashlog | cut -f 1 | sort -nr | awk '{ print NR" "$1 }') <(cat hashlog | awk '{ print NR" "$0 }') | 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'