… to allow an own implementation of the git protocol without breaking clients. It also includes interfaces for the fetchinfo and pushinfo types

…of running. Currently it requires an object implementation which will be ported next. None of the tests is expected to run yet.

…it-python for now as it requires plenty of additional features which are currently only available via the git command

…more 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.

…cts in the database for some reason.

…it_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

…ntioned 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

…. This 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

…ory 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

…n is 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

…om 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.

…ork to do

…work starts. Oh my ...