Bug#663941: Cannot rebase commits at midnight, 1 Jan 1970 (epoch 0)

2014-01-06 Thread Trent W. Buck
Jonathan Nieder wrote: Version: 1:1.7.9.1-1 notfound 663941 git/1:1.7.9.1-1 quit Zbigniew Jędrzejewski-Szmek wrote: I just tested this, and with v1.7.9.1~8 I get the error message fatal: invalid date format: 0 +, and with v1.7.9.1~7 (i.e. after the branch with the supposed fix is

Bug#663941: Cannot rebase commits at midnight, 1 Jan 1970 (epoch 0)

2012-06-14 Thread Zbigniew Jędrzejewski-Szmek
On 06/14/2012 07:05 AM, Jonathan Nieder wrote: Hi Zbyszek, Zbigniew Jędrzejewski-Szmek wrote: this is indeed fixed now. Thanks for testing. Any idea what version fixed it? According to the original report, Trent ran into this using git 1:1.7.9.1-1. I just tested this, and with

Bug#663941: Cannot rebase commits at midnight, 1 Jan 1970 (epoch 0)

2012-06-13 Thread Jonathan Nieder
Hi Zbyszek, Zbigniew Jędrzejewski-Szmek wrote: this is indeed fixed now. Thanks for testing. Any idea what version fixed it? According to the original report, Trent ran into this using git 1:1.7.9.1-1. Curious, Jonathan Testcase: git init repo cd repo git commit -m one --allow-empty

Bug#663941: Cannot rebase commits at midnight, 1 Jan 1970 (epoch 0).

2012-03-14 Thread Trent W. Buck
Package: git Version: 1:1.7.9.1-1 Severity: wishlist When creating a test repo to demonstrate a problem, I deliberately forced commit dates to the most obvious date -- epoch zero: $ git filter-branch --env-filter 'export GIT_AUTHOR_DATE=$(TZ=UTC date -d@0 -R)' $ git rebase -f HEAD~1

Bug#663941: Cannot rebase commits at midnight, 1 Jan 1970 (epoch 0)

2012-03-14 Thread Jonathan Nieder
Hi Trent, Trent W. Buck wrote: Ah, sorry, my test of @1 was wrong, because that is also not accepted. #git on Freenode indicated that git considers dates before ca. 1975 obviously wrong and rejects them. So I guess this is WONTFIX, this is by design. This area has changed recently and