| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
v2 is chosen to better match the name.
|
| |\
| |
| | |
support optional gitdb_speedups
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Do not support universal wheels
My comment from github for context:
```
As I am not quite sure about the impact of the C-code and the overall maintenance and distribution burden, I would rather remove it entirely.
In the current implementation using setup.py it would try to build the code, and just keep going on failure. Something like that I would love to have for the wheel as well.
Alternatively, maybe it's possible to keep supporting the setup.py for those who want to have a chance to improved performance, and those who use wheels will still get the python-only version.
I will just merge the commit for now, but do indeed hope there is a way to make this work.
```
|
| |/
|
| |
because you need to build manylinux1/mac/windows wheels instead
|
| |\
| |
| | |
Support universal wheels
|
| |/ |
|
| |\
| |
| | |
Handle more file open/close with "with"
|
| | | |
|
| |\ \
| | |
| | | |
Spelling fixes
|
| | |/ |
|
| |\ \
| |/
|/| |
Add Python 3.5 to tests and classifiers
|
| | | |
|
| |/ |
|
| |
|
| |
Fixes #25
|
| | |
|
| |
|
|
|
|
| |
This should workaround possible permission issues.
Related to https://github.com/gitpython-developers/GitPython/issues/353
|
| | |
|
| |\
| |
| | |
Remove duplicate `const`
|
| |/
|
|
| |
Remove duplicate `const` to stop the warning: "duplicate 'const' declaration specifier"
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |/ |
|
| |
|
|
|
|
|
| |
Therefore, hardcoded sha's are not allowed anymore, as the contents of
the repository is unknown.
Fixes #16, for real this time ;)
|
| | |
|
| |
|
|
|
|
|
| |
I have verified that all tests are working, even without a parent
git repository, as long as the said environment variable is set.
Fixes #16
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
| |
Configured travis to artificially restrict handle count to protect
from regression in that regard
|
| | |
|
| | |
|
| |
|
|
| |
Now we deal with memory views as well ...
|
| |
|
|
| |
Adjusted sublime project too
|
| |
|
|
| |
And bumped version to 0.6.2
|
| |
|
|
| |
It doesn't do anything (in terms of fixing an issue), but it should be more correct than what was there previously
|
| |
|
|
| |
autopep8 -v -j 8 --max-line-length 120 --in-place --recursive
|
| |
|
|
|
|
|
|
| |
just packs
This should make it easier to assert the issue is truly fixed now
[skip ci]
|
| |\ |
|
| | |\
| | |
| | | |
Bring gitdb.test back into distribution
|
| | |/ |
|
| | |
| |
| |
| | |
Fixed tiny issue in python 3
|
| | |
| |
| |
| |
| |
| | |
the issue described in https://github.com/gitpython-developers/GitPython/issues/220
See test notes for proper usage, it all depends on a useful dataset with high entropy
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
information
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
|
| | |
|
| |\
| |
| |
| |
| | |
* python 3 compatibility
* all tests work in py2.6, 2.7, 3.3, 3.4
|
| | |
| |
| |
| | |
This also explains why the tests suddenly stopped working - after all, the interpreter changed ... .
|
| | |
| |
| |
| | |
Maybe I can find a py 2.6 interpreter somewhere to reproduce it.
|
| | | |
|