diff options
author | Junio C Hamano <gitster@pobox.com> | 2012-02-02 13:41:42 -0800 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2012-02-03 23:11:32 -0800 |
commit | 116eb3abfe4f79907f701317c2d905868941fff7 (patch) | |
tree | 09c4cafc205ee3cb2bb5fbe41b5a4f268668fa7c /t/t4133-apply-filenames.sh | |
parent | Git 1.7.7 (diff) | |
download | tgif-116eb3abfe4f79907f701317c2d905868941fff7.tar.xz |
parse_date(): allow ancient git-timestamp
The date-time parser parses out a human-readble datestring piece by
piece, so that it could even parse a string in a rather strange
notation like 'noon november 11, 2005', but restricts itself from
parsing strings in "<seconds since epoch> <timezone>" format only
for reasonably new timestamps (like 1974 or newer) with 10 or more
digits. This is to prevent a string like "20100917" from getting
interpreted as seconds since epoch (we want to treat it as September
17, 2010 instead) while doing so.
The same codepath is used to read back the timestamp that we have
already recorded in the headers of commit and tag objects; because
of this, such a commit with timestamp "0 +0000" cannot be rebased or
amended very easily.
Teach parse_date() codepath to special case a string of the form
"<digits> +<4-digits>" to work this issue around, but require that
there is no other cruft around the string when parsing a timestamp
of this format for safety.
Note that this has a slight backward incompatibility implications.
If somebody writes "git commit --date='20100917 +0900'" and wants it
to mean a timestamp in September 2010 in Japan, this change will
break such a use case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4133-apply-filenames.sh')
0 files changed, 0 insertions, 0 deletions