delta/python-packages/gitdb.git/gitdb/stream.py, branch 3.0.0 github.com: gitpython-developers/gitdb.git support optional gitdb_speedups 2016-10-04T17:05:26+00:00 Thomas Grainger tom.grainger@procensus.com 2016-10-04T17:04:24+00:00 62815b5c5a4c39e9ace3d20ec0c593011201dbcf 






Spelling fixes
2016-07-27T06:32:29+00:00

Ville Skyttä
ville.skytta@iki.fi

2016-07-27T06:32:29+00:00

2af455266cb3ea454c4f38b182825b9e78b8398d












Adjusted stream logic to make it work on all tested platforms ... .
2015-01-12T18:10:42+00:00

Sebastian Thiel
byronimo@gmail.com

2015-01-12T18:10:42+00:00

5b0dc5f89a666f450f39ef0002cf6d1761ecfca8

As taken from https://github.com/gitpython-developers/gitdb/blob/master/gitdb/stream.py#L292
->
NOTE: Behavior changed in PY2.7 onward, which requires special handling to make the tests work properly.
They are thorough, and I assume it is truly working.
Why is this logic as convoluted as it is ? Please look at the table in
https://github.com/gitpython-developers/gitdb/issues/19 to learn about the test-results.
Bascially, on py2.6, you want to use branch 1, whereas on all other python version, the second branch
will be the one that works.
However, the zlib VERSIONs as well as the platform check is used to further match the entries in the
table in the github issue. This is it ... it was the only way I could make this work everywhere.
IT's CERTAINLY GOING TO BITE US IN THE FUTURE ... .
<-

Fixes #19





As taken from https://github.com/gitpython-developers/gitdb/blob/master/gitdb/stream.py#L292
->
NOTE: Behavior changed in PY2.7 onward, which requires special handling to make the tests work properly.
They are thorough, and I assume it is truly working.
Why is this logic as convoluted as it is ? Please look at the table in
https://github.com/gitpython-developers/gitdb/issues/19 to learn about the test-results.
Bascially, on py2.6, you want to use branch 1, whereas on all other python version, the second branch
will be the one that works.
However, the zlib VERSIONs as well as the platform check is used to further match the entries in the
table in the github issue. This is it ... it was the only way I could make this work everywhere.
IT's CERTAINLY GOING TO BITE US IN THE FUTURE ... .
<-

Fixes #19







minor spell fixes + empty line unification + comparison for python 2.6
2015-01-08T18:11:57+00:00

Yaroslav Halchenko
debian@onerussian.com

2015-01-08T18:10:28+00:00

13ad9b1199331a35e23f65c735acf482be09eae3












Protected stream closure against possibilty of being a bytes
2015-01-07T18:57:19+00:00

Sebastian Thiel
byronimo@gmail.com

2015-01-07T18:57:19+00:00

be294278a0087f21d565a1084fb220ff936ae0bd

For some reason, it gets bytes where it did expect a stream ... .
Probably I should have figured out where this was input, instead
of fixing it the brutal way





For some reason, it gets bytes where it did expect a stream ... .
Probably I should have figured out where this was input, instead
of fixing it the brutal way







Fixed possible file-handle leak
2015-01-07T17:09:45+00:00

Sebastian Thiel
byronimo@gmail.com

2015-01-07T17:09:45+00:00

560a211001064261eb25ca874980591790fb7986

Configured travis to artificially restrict handle count to protect
from regression in that regard





Configured travis to artificially restrict handle count to protect
from regression in that regard







Applied autopep8
2015-01-04T10:21:36+00:00

Sebastian Thiel
byronimo@gmail.com

2015-01-04T10:21:36+00:00

ff7615321ee31d981a171f7677a56a971c554059

autopep8 -v -j 8 --max-line-length 120 --in-place --recursive





autopep8 -v -j 8 --max-line-length 120 --in-place --recursive







Increased initial size of decompressed data to obtain loose object header information
2015-01-01T12:47:19+00:00

Sebastian Thiel
byronimo@gmail.com

2015-01-01T12:47:19+00:00

c38bd19706abe5cf0bf0e7b3e9ad2b3e554d28ef

This appears to fix https://github.com/gitpython-developers/GitPython/issues/220 , in this particular case.
Nonetheless, we might just have gotten lucky here, and the actual issue is not yet solved and can thus re-occour.
It would certainly be best to churn through plenty of loose objects to assure this truly works now. Maybe the pack could be recompressed as loose objects
to get a sufficiently large data set





This appears to fix https://github.com/gitpython-developers/GitPython/issues/220 , in this particular case.
Nonetheless, we might just have gotten lucky here, and the actual issue is not yet solved and can thus re-occour.
It would certainly be best to churn through plenty of loose objects to assure this truly works now. Maybe the pack could be recompressed as loose objects
to get a sufficiently large data set







It seems zlib works differently in py26, and thus requires special handling.
2014-11-14T11:40:22+00:00

Sebastian Thiel
byronimo@gmail.com

2014-11-14T11:39:09+00:00

0dcec5a27b341ce58e5ab169f91aa25b2cafec0c

This also explains why the tests suddenly stopped working - after all, the interpreter changed ... .





This also explains why the tests suddenly stopped working - after all, the interpreter changed ... .







Fixed incorrect computation of compressed bytes read in zlib decompression stream.
2014-11-14T09:43:28+00:00

Sebastian Thiel
byronimo@gmail.com

2014-11-14T09:43:28+00:00

232cf20efaef4218a71c348b0f59c5e59c59cbdb