| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Needs plenty of work
|
| |
|
|
| |
implemented now - depending on the performance, it might actually receive some more work
|
| |
|
|
|
|
| |
everything from the existing implementation, but one by one things can be reimplmented to use dulwich.
It also shows that py 2.6 is quite plagued from its new feature, which is actually a bug, as objects inability to accept any args makes mixins hard to use ...
|
| | |
|
| |
|
|
| |
git versions. This bug existed for quite a while but didn't show up as progress wasn't sent most of the time. All methods that could use a progress will only activate it if a progress is actually given
|
| |
|
|
| |
figured out that the implementation really should be specific to the git command. This leaves the interface open for other implemntations which use a different way to provide feedback (as we do not make assumptions about the format of a feedback line)
|
| |
|
|
| |
similar functionality as used by the fetch, push and pull methods
|
| |
|
|
|
|
| |
implementations. It seems theoretically work together now, although it clearly is much more complex than ever before.
The repo package was slimmed down to being a module once again, which is only there for compatability actually
|
| |
|
|
| |
methods on the default Repo implementation into interfaces or something that can be abstracted. It shows that it would indeed be good to keep the differentiation between Repositories which contain an object database as it is clearly easier to setup any combination of repositories that use git and those that do not, with just the addition of one more level of indirection. Lets see how it will end up
|
| |
|
|
| |
repo interface. Added submodule interface ... goal is to provide all of the extra repo functionality in custom interfaces
|
|
|
Then the tests will need some work
|
