What is the format for --date parameter of git commit
Solution 1:
Git 2.6+ (Q3 2015) add a new option.
See commit e4f031e (30 Jun 2015), and commit aa1462c, commit a5481a6, commit b7c1e11 (25 Jun 2015) by Jeff King (peff
).
(Merged by Junio C Hamano -- gitster
-- in commit d939af1, 03 Aug 2015)
introduce "format" date-mode
This feeds the format directly to
strftime
.
Besides being a little more flexible, the main advantage is that your systemstrftime
may know more about your locale's preferred format (e.g., how to spell the days of the week).
--date=format:...
feeds the format...
to your systemstrftime
.
Use--date=format:%c
to show the date in your system locale's preferred format.
See thestrftime
manual for a complete list of format placeholders.
Davide Cavestro proposes in the comments the example:
git commit -m "Test" --date=format:relative:5.hours.ago
Original answer (mid 2014)
The --date
option (introduced in commit 02b47cd in Dec. 2009, for git1.7.0) uses the same format than for GIT_AUTHOR_DATE
, with date formats tested in commit 96b2d4f:
There you can see the various format accepted:
- rfc2822:
Mon, 3 Jul 2006 17:18:43 +0200
- iso8601:
2006-07-03 17:18:43 +0200
- local:
Mon Jul 3 15:18:43 2006
- short:
2006-07-03
(not in 1.9.1, works in 2.3.0) -
relative: see commit 34dc6e7:
5.seconds.ago, 2.years.3.months.ago, '6am yesterday'
raw: see commit 7dff9b3 (git 1.6.2, March 2009)
internal raw git format - seconds since epoch plus timezone
(put another way: 'date +"%s %z"
' format)- default:
Mon Jul 3 17:18:43 2006 +0200
ADTC asks and answers in the comments:
Does it accept 2006-07-03 15:18:43 for local?
Yes it does work and it takes the local time zone automatically.
With that format I don't need to bother which day of the week it is (Sun
,Mon
, etc).
Solution 2:
The date format is underdocumented at Documentation/date-formats.txt (man git commit
), and very "humanishely" parsed.
The only thing that works is reading the source under date.c and trying it out.
Points not mentioned by VonC on 2.3.0:
-
digits only are parsed depending on the number of digits:
2 digits: 19YY , for YY >= 73, current month, day and time. Errors or current date otherwise.
4 digits: YYYY , for YYYY >= 1973, <= 2099
> 8 digits up to some small limit (TODO which?): UNIX time (seconds since 1970)
-
@<digits> +0000
: UNIX time.This seems like the best way to enter UNIX times directly.
2**64 - 2 (TODO why not -1 ?) was the maximum value that does not lead to a commit error. The stamp is stored in a C long.
git log
shows very large values (somewhere around2^55
TODO where?) as 1970, even thoughgit cat-file -p HEAD
shows that the right number was stored, so it seems like a limitation of the date conversion.For anything larger than
2**63 - 1
, the largest positive signed long, trying to push to GitHub fails withdate causes integer overflow
. A commit at that date on GitHub (GitHub cannot show really large dates for some reason)VonC pointed that this is a shame as it blocks negative dates Is it possible to set a git commit to have a timestamp prior to 1970? which could be used to migrate older software to Git.
tea
: today at 17h :-)
Solution 3:
Simple example:
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'
Solution 4:
The abbreviated forms below would all work:
<month>/<day>
<month>-<day>
<day>.<month>
When there's no ambiguity, namely <day>
is greater than 12
, the order of <month>
<day>
doesn't matter, and the separator could be any of '/
', '-
', or '.
'.
Otherwise, use '.
' as separator for <day>.<month>
, and '/
' or '-
' for <month>-<day>
.
So "1.7
" would be treated as "July 1st", and "1/7
" would be "January 7th".
See the related commit from v1.3.0:
We learned from our European friends on the #git channel that dd.mm.yyyy is the norm there.
When the separator is '.', we prefer dd.mm.yyyy over mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over dd/mm/yy[yy].
This also applies to other commands accepting date input, e.g.: to show log since Feb 4th:
git log --since 2/4