summaryrefslogtreecommitdiff
path: root/git-gui/git-gui--askpass
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2012-02-02 13:41:42 -0800
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-02-03 23:11:32 -0800
commit116eb3abfe4f79907f701317c2d905868941fff7 (patch)
tree09c4cafc205ee3cb2bb5fbe41b5a4f268668fa7c /git-gui/git-gui--askpass
parentGit 1.7.7 (diff)
downloadtgif-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 'git-gui/git-gui--askpass')
0 files changed, 0 insertions, 0 deletions