Closed
Description
First failed while building 1.0.1 so decided to check current snapshot -- the same story:
hopa:~deb/build-area/python-git-1.0.1+git72-g039e265
$> GIT_PYTHON_TEST_GIT_REPO_BASE=$PWD/build/test/GitPython nosetests -s -v --pdb git/test/performance/test_commit.py
test_commit_iteration (git.test.performance.test_commit.TestPerformance) ... Iterated 1250 Commits in 0.108746051788 [s] ( 11494.670192 commits/s )
ok
test_commit_serialization (git.test.performance.test_commit.TestPerformance) ... > /home/yoh/deb/gits/build-area/python-git-1.0.1+git72-g039e265/git/test/test_commit.py(57)assert_commit_serialization()
-> assert istream.hexsha == cm.hexsha.encode('ascii')
(Pdb) print istream.hexsha
66aa07976c27f9de05fd2da30f09627f365154ef
(Pdb) cm.hexsha.encode('ascii')
'e3068025b64bee24efc1063aba5138708737c158'
(Pdb) l
52 ns += 1
53 streamlen = stream.tell()
54 stream.seek(0)
55
56 istream = rwrepo.odb.store(IStream(Commit.type, streamlen, stream))
57 -> assert istream.hexsha == cm.hexsha.encode('ascii')
58
59 nc = Commit(rwrepo, Commit.NULL_BIN_SHA, cm.tree,
60 cm.author, cm.authored_date, cm.author_tz_offset,
61 cm.committer, cm.committed_date, cm.committer_tz_offset,
62 cm.message, cm.parents, cm.encoding)
$> locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
$> apt-cache policy python-gitdb
python-gitdb:
Installed: 0.6.4-1
Candidate: 0.6.4-1
Version table:
*** 0.6.4-1 0
300 http://http.debian.net/debian/ experimental/main amd64 Packages
100 /var/lib/dpkg/status
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
yarikoptic commentedon Aug 16, 2015
so any ideas or instructions on what/how to test to provide more information to pin point what is going on?
Byron commentedon Aug 16, 2015
Sorry for the late reply, lot's of stuff is happening around here.
It seems I can nicely reproduce the issue, and must say that I absolutely don't like it. Right now I have no clue why it occours, but a bisect would certainly help in that regard.
No sooner said than done ! The commit 58c78e6 is the one introducing the issue - probably the commit message is now a different one.
It managed to sneak by CI as it doesn't run performance tests - it would take too long there.
Now a fix is most certainly possible, let's see if I will manage it tonight.
fix(commit): serialization timezone handling
Byron commentedon Aug 17, 2015
I found the issue - it's actually a critical flaw, which is now, finally fixed. This is a zero-day bug I suppose, and if not it's very old at least.
I'd be happy if you could verify the fix on your end and close the issue if it works for you.
Thanks
yarikoptic commentedon Aug 18, 2015
Thank you @Byron -- this issue seems to be gone now! But I will file a fresh one in a sec ;)
yarikoptic commentedon Sep 1, 2015
FWIW -- feedback was provided
adjusted version for more recent snapshot to see if the reported issue …