| Age | Commit message (Collapse) | Author |
|
everything. Includes an updated config file which includes all the new additions
|
|
The regex comments state that any number of leading tabs or spaces
should be allowed, however the regex was only catching zero or one
space. This allows multiple spaces.
|
|
|
|
any push or fetch operation
|
|
Instead it allows the user to override the type in the classmethod he calls. Otherwise the type of the own repo will be respected
|
|
|
|
|
|
|
|
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
|
|
|
|
consolidation changes from master to make clone use the same facilities
|
|
fast with nearly now overhead if the data streams in fast enough (~30 MB/s when writing a pack). This shows that there is huge potential for sending packs, considering that we are actually recompressing them (without deltification). To be faster in future, we could probably just send ref-deltas or full objects as found in the pack without doing any recompression.
|
|
This could cause several copies to exist, and makes the cmd implementation a bad choice if big files are involved
|
|
database (as streams have to be decompressed, it should be redesigned to have multiple database implementations)
|
|
indicate what it tests
|
|
|
|
command implementations. The previous performance test was truncated a bit as it compared directly with the git hash_object write performance. This is out, and if we wanted it we could implement it , but its actually slower for us
|
|
be tested as well at some point
|
|
future implementations to use the test as well
|
|
|
|
|
|
false positives in repositories that are freshly checked out
|
|
tests need some more work. Also, the tests need to be reorganized and move closer to their actual location within gitpython. Hence the refs tests go to git.test.refs, etc
|
|
more work as the amount of submodules changed in fact. Maybe I should just generate a test repository with gitpython as submodule to get the recursion depth required to satisfy the test
|
|
|
|
|
|
|
|
|
|
the test suggests. Pure python implementation still has some trouble, but this should be very fixable
|
|
of the new database types. This reduces code duplication to the mere minimum, but allows custom tests to be added on top easily and flexibly
|
|
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
|
|
changed drastically. Now the actual work begins
|
|
|
|
|
|
Then the tests will need some work
|
|
submodule just yet)
|
|
changes when doing the merge
|
|
is still to be fixed of course
|
|
by its gitdb counterpart through inheritance. All items which are part of gitdb but used by gitpython need their own verification within gitpython
|
|
submodule implementation is left in git-python as it requires some advanced features. No tests where run yet
|
|
git command. everything else was moved to GitDB. None of the tests is yet expected to run, although git-python should have less trouble getting the tests back up running than GitDB. plenty of code needs to be de-duplicated though in case of the tests, which will be some work
|
|
implementation, including related types. It doesn't yet work, and the omnipresence of the repo imposes a problem right now, as the required ref functionality is not yet part of the gitdb specification. theoretically, the whole ref implementation has to move into gitdb
|
|
aid packagers a bit
|
|
looked like hexshas. Thanks to Ning (frostyplanet) who pointed this issue out
|
|
self.head.* in order to more safely get the current commit. active_branch would only work on non-detached heads
|
|
the error was caused by PySide which, when instantiating a QApplication, changed the signal handlers to interrupt, instead of retry operating system calls, which caused git-python to fail subsequently. signal.siginterrupt can be used to fix this behaviour after an QApplication was instatiated.
|
|
platform.system makes a system call itself
|