| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
starts. Oh my ...
|
| |
|
| |
|
| |
|
|
|
|
| |
future ones. This will change plenty of imports, which still needs to be fixed. Fortunately, this is a good foundation for getting all the tests fixed one again. Another step is to make the tests more flexible by allowing to run them with different object database easily.
|
|
|
|
| |
still a mess, it really needs to be separated into interfaces and implementations, sorted by type , like pure, pygit(at some point) and so on. This would already allow database implementations to be mixed and matched. One further step to be taken another day would be to 'interfacify' object and reference types, so they could be replaced by different implementations as well including full isinstance support (as isinstance would only check for the base interface). To ease this, the interfaces would just keep their original names, but the implementation would move to types like PureObject, PureSymbolicReference, etc. etc
|
|
|
|
| |
with reference support, as opposed to a plain odb which objects are already happy with. Tests now work up to the point where a rev-parse is required. This could be helped, but revparse could also be implemented somewhere which was the reason for pulling in so much code in the first place
|
|
|
|
| |
showed that we need to distinguish between plain object dbs with a respective interface and full repositories, which have references and remotes. Ideally, the ones that require only odbs use the odb member, others use the repo member
|
|
|
|
| |
one still needs to be implemented, and integrated into type hierarchy to be actually useful. A test for the RepositoryPathsMixin would be required as well
|
|
|
|
| |
git_dir() providing repository. Currently there is no separate interface for this, which might have to be added at some point just for the sake of completeness
|
|
|
|
| |
the database for some reason.
|
|
|
|
|
|
| |
throrough changes based on the interfaces actually available in gitdb. This should work though as all references have iter_* methods which do the actual work.
Added git config parser to the mix, including working test - the module is not very interdependent, fortunately.
|
|
|
|
| |
git-python for now as it requires plenty of additional features which are currently only available via the git command
|
|
|
|
| |
running. Currently it requires an object implementation which will be ported next. None of the tests is expected to run yet.
|
|
|
|
| |
allow an own implementation of the git protocol without breaking clients. It also includes interfaces for the fetchinfo and pushinfo types
|
|
|
|
|
|
| |
I think it never successfully imported, but its hard to believe this slipped by.
Added performance test for pack-writing, which isn't really showing what I want as it currently read data from a densly compressed pack which takes most of the time in the nearly pure python implementation. Compared to c++, all the measured performance is just below anything I'd want to use. But we shouldn't forget this is just a test implementation, writing packs is quite simple actually, if you leave out the delta compression part and the delta logic
|
| |
|
|
|
|
| |
wrong with my packs. Probably something stupid ;)
|
|
|
|
| |
more testing and verification
|
|
|
|
| |
streaming over a transport as well
|
| |
|
| |
|
| |
|
| |
|
|
Submodule relinked to point to new github location, and moved as well
|