| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Strip the last line of the output if it is empty (default). Stripping should be
disabled whenever it is important that the output is not modified in any way.
For example when retrieving patch files using git-diff.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug when parsing blame -p output: Full commit info headers
only appear for the first line from a particular commit, but other lines
were ignored as the blame info dict was reset after each line.
This patch handles both multiple consecutive lines from a commit and
interleaved lines from multiple commits.
Added real test to verify blame works against the actual commit, not
only a mock of what was produced by blame in old git releases
|
|
|
|
| |
tests only work reliably in a patched up version, or the next point release.
|
|
|
|
| |
implemented now - depending on the performance, it might actually receive some more work
|
| |
|
|
|
|
| |
least, which implicitly includes pack handling. For the pack specific tests to work, one would need a pack interface though, which is currently not planned to be specifically exposed
|
|
|
|
|
|
| |
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 ...
|
|
|
|
| |
things after all
|
|
|
|
| |
module was not found. Its actually a nice mix between decorators which are class types, and a mixin as a metaclass, which applies said decorator. The InstanceDecorator wouldn't actually be needed, but it adds flexibility. Maybe it should be removed ...
|
|
|
|
| |
surface while integrating this
|
| |
|
|
|
|
|
|
|
| |
optimal results in all cases (at least the ones I can test)
pack: now works properly with a sliding memory manager
test_packedodb_pure: fixed very memory hungry implementation by using an iterator. This will of course reduce the measured performance a bit, but 750MB of memory is just a little bit too much for an ordinary test. Maybe it would be alright to just reduce the number of items ... but performance isn't a strength of python after all
|
|
|
|
| |
#24, #25
|
|
|
|
| |
including simple test
|
| |
|
|
|
|
| |
help the submodule test to work even on windows
|
|
|
|
| |
submodule tests to run
|
| |
|
|
|
|
| |
expect a stream
|
|
|
|
| |
Fixed possible issue in test_refs, which occurred in 0.3 previously
|
|
|
|
| |
functionality
|
|
|
|
|
|
| |
resemble their actual location a little more.
Renamed test_git to test_cmd as it tests the git cmd located in git.cmd (not in git.git)
|
| |
|
|
|
|
| |
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
|
|
|
|
| |
everything. Includes an updated config file which includes all the new additions
|
| |
|
| |
|
|
|
|
| |
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)
|
| |
|
|
|
|
| |
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.
|
|
|
|
| |
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
|
|
|
|
| |
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
|