Який формат для параметра --date параметра git commit


79

Мені потрібно переписати дату коміту git, вся документація вказує на параметр --date, але потім залишає одну без підказки до відповідного формату. Я перепробував усі перестановки, які мені здаються, і я отримую помилку "фатально: недійсний формат дати:" для кожного.


1
Що деякі відповіді на це питання частково відповідають моєму. Я щойно перевірив, і це працює. До речі, вам не потрібно вводити там день тижня (це було б боляче).
v010dya

Відповіді:


84

Git 2.6+ (Q3 2015) додав нову опцію.

Див. Коміт e4f031e (30 червня 2015 р.) Та коміт aa1462c , коміт a5481a6 , коміт b7c1e11 (25 червня 2015 р.) Джеффом Кінгом ( peff) .
(Об’єднано Junio ​​C Hamano - gitster- у комітеті d939af1 , 03 серпня 2015 р.)

ввести "формат" дата-режим

Це подає формат безпосередньо в strftime.
Окрім того, що вона трохи гнучкіша, основною перевагою є те, що ваша система strftimeможе знати більше про бажаний формат вашої мови (наприклад, як правильно писати дні тижня).

--date=format:...подає формат ...до вашої системи strftime.
Використовуйте --date=format:%cдля відображення дати у бажаному форматі локальної системи. Повний список заповнювачів формату
див. У strftimeпосібнику.

Давіде Кавестро пропонує в коментарях приклад:

git commit -m "Test" --date=format:relative:5.hours.ago 

Оригінальна відповідь (середина 2014 р.)

--dateВаріант (введений в фіксації 02b47cd в грудні 2009 року, для git1.7.0) використовує той же формат , ніж для GIT_AUTHOR_DATE, з зазначенням дати форматів тестованих в фіксації 96b2d4f :

Там ви можете побачити різноманітний формат:

  • rfc2822: Mon, 3 Jul 2006 17:18:43 +0200
  • iso8601: 2006-07-03 17:18:43 +0200
  • місцевий: Mon Jul 3 15:18:43 2006
  • короткий: 2006-07-03(не в 1.9.1, працює в 2.3.0)
  • відносна: див. коміт 34dc6e7 :

    5.seconds.ago, 
    2.years.3.months.ago, 
    '6am yesterday'
    
  • raw: див. коміт 7dff9b3 (git 1.6.2, березень 2009 р.),
    внутрішній вихідний формат git - секунди з епохи плюс часовий пояс
    (по-іншому: date +"%s %z"формат ' ')

  • за замовчуванням: Mon Jul 3 17:18:43 2006 +0200

ADTC запитує та відповідає у коментарях :

Чи приймає він 03.07.2006 15:18:43 як місцевий?

Так, це працює, і він автоматично приймає місцевий часовий пояс.
З цим форматом не потрібно турбуватися , який день тижня це ( Sun, Monі т.д.).


Чи приймає це 2006-07-03 15:18:43для місцевого ? Крім того, що таке відносні та необроблені формати?
ADTC

Щоб відповісти на власне перше запитання, так, це спрацьовує, і він автоматично приймає місцевий часовий пояс. З таким форматом мені не потрібно турбуватись, який це день тижня (сонце, пн тощо).
ADTC

1
@ADTC Я додав посилання та посилання на відносний та вихідний формат дати. Я включив ваш коментар у відповідь для більшої наочності.
VonC

1
@CiroSantilli не впевнений: це може бути гарним окремим питанням. Я протестую його з 1.9.4.
VonC

1
@CiroSantilli 六四 事件 法轮功 Дякуємо за редагування, чудово бачити цей короткий формат у 2.3.0.
VonC

8

Формат дати недокументований в Documentation / date-formatats.txt ( man git commit) і дуже «гуманітарно» проаналізований.

Єдине, що працює, - це прочитати джерело в date.c та спробувати його.

Точки, не зазначені VonC на 2.3.0:

  • аналізуються лише цифри залежно від кількості цифр:

    • 2 цифри: 19РР, для РР> = 73, поточний місяць, день та час. Помилки або поточна дата в іншому випадку.

    • 4 цифри: РРРР, для РРРР> = 1973, <= 2099

    • > 8 цифр до деякого малого обмеження (TODO який?): Час UNIX (секунди з 1970 р.)

  • @<digits> +0000: Час UNIX.

    Це здається найкращим способом безпосереднього введення часу UNIX.

    2 ** 64 - 2 (TODO, чому б не -1?) Було максимальним значенням, яке не призвело до помилки коміту. Марка зберігається в довжині C.

    git logпоказує дуже великі значення (десь приблизно 2^55TODO, де?), як 1970, хоча git cat-file -p HEADпоказує, що було збережено правильне число, тому це здається обмеженням перетворення дати.

    Для будь-чого більшого, ніж 2**63 - 1, найбільший позитив підписав довго, намагаючись натиснути на GitHub не вдається date causes integer overflow. Фіксація на ту дату на GitHub (GitHub чомусь не може показувати справді великі дати )

    VonC зазначив, що це ганьба, оскільки блокує негативні дати. Чи можна встановити git-коміт, щоб мати позначку часу до 1970 року? який можна використовувати для перенесення старішого програмного забезпечення на Git.

  • tea: сьогодні о 17h :-)


Зверніть увагу , що з Git РЕПО ініціатив в залежності від дати (як цей: stackoverflow.com/q/29385441/6309 ), дати до 1970 року буде приємно: stackoverflow.com/a/24977895/6309
VonC

3
@VonC: приємне посилання. Вона не приходила мені в голову , що контроль версій існує з 60 - х / 70 - х programmers.stackexchange.com/questions/184695 / ... і текст , так як -3200 року. Що робити, якщо вони хочуть перенести код хаммурапі в Git? :-) (ах, щойно дізнався, що хтось це вже зробив: github.com/elia/hammurabi/blob/master/lib/hammurabi/code.txt , але втратив позначки часу)
Ciro Santilli 郝海东 冠状 病 六四 事件法轮功

3

Простий приклад:

GIT_AUTHOR_DATE='2015-04-19 17:18:43 +0200' GIT_COMMITTER_DATE='2015-04-19 17:18:43 +0200' git commit -m 'Commit message'

Здається, що використання змінних середовища є єдиним способом встановити дату коміту. Для цього немає аргументів.
Ярл,

1

Скорочені форми нижче будуть працювати:

  1. <month>/<day>
  2. <month>-<day>
  3. <day>.<month>

Коли немає двозначності, а саме <day>більше ніж 12, порядок <month> <day>не має значення, і роздільник може бути будь-яким із символів /'', ' -' або ' .'.

В іншому випадку використовуйте ' .' як роздільник для <day>.<month>, та ' /' або ' -' для <month>-<day>.

Тож " 1.7" буде трактуватися як "1 липня", а " 1/7" буде "7 січня".

Див . Пов’язаний коміт з v1.3.0 :

Коли роздільник ".", Ми віддаємо перевагу ддмм.рррр перед
мм.дд.ррррр; інакше mm / dd / yy [yy] має перевагу над
дд / мм / рр [рр].

Це також стосується інших команд, що приймають введення дати, наприклад: показати журнал з 4 лютого:

git log --since 2/4
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.