| 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.
|
| | |
|
| | |
|
| |
|
|
| |
potentially fixes https://github.com/gitpython-developers/GitPython/issues/36
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Incorrect handling of backslashes and quotes in GitConfigParser
Steps to reproduce the issue:
import git
config = git.Repo().config_writer()
config.add_section('test')
config.set_value('test', 'test', r'some\data')
Now if you try to read this value using a regular (non Python) git config, Git complains that the configuration file is invalid:
fatal: bad config file line 11 in .git/config
Indeed, if you open .git/config you can see that the value is written as:
[test]
test = some\data
While the git-config configuration states that:
String values may be entirely or partially enclosed in double quotes. You need to enclose variable values in double quotes if you want to preserve leading or trailing whitespace, or if the variable value contains comment characters (i.e. it contains # or ;). Double quote " and backslash \ characters in variable values must be escaped: use \" for " and \ for .
That is, the backslashes are not escaped in the configuration file.
This also causes issues while reading, because values are not un-escaped.
This pull request fixes both those issues and also fixes unescaped quotes pairs.
A test-case has been provided along with the fixes.
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Fixed 'Inappropriate ioctl for device' problem on posix systems
Without an active login shell on linux or osx, we now use the password database to obtain the active login, instead of relying on environment variables).
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
When command run as subprocess, AutoInterrupt will kill the
process on destructor. However, if process already finished,
it raise OSError exception.
This fix just ignore OSError on os.kill.
|
| |/
|
|
|
|
|
| |
Currently if command is called with as_proces=True, pipes for the
command will not be closed.
This change makes sure to close command file descriptors.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
enough for the first batch of work
|
| |
|
|
| |
actually
|
| |
|
|
| |
inefficient, but can't help it. Basic repo tests don't work as dulwich ignores alternate files
|
| | |
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
installation puts it into the path, instead of git.exe. Of course we warn about the performance penalty that goes with it. Fortunately, using a wrapped git.exe works when creating pipes to the process, admittedly I was a bit surprised by this.
fixes #26
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
pack: now using the global sliding memory manager. The current implementation uses assumes that packs are small enough to fit into memory right away, where the window size will be about 1 GB, as it never calls use_window() to assure the required offset actually exists. It will need to change to set the window appropriately.
|
| |
|
|
| |
available
|
| |
|
|
| |
#24, #25
|
| |
|
|
| |
useful for tags as well, which might end up somewhere in the refs/remotes space. Its not likely that it will ever be used on a pure Reference instance though, but it is the smallest common base
|
| |
|
|
| |
including simple test
|
| |
|
|
| |
thanks to the rpartition method. omg
|
| | |
|
| |
|
|
| |
read-only files to be removed on windows as well
|
| |
|
|
| |
partial or intermixed lines from the pipe. This really shouldn't be, but its windows so it happens
|
| |
|
|
| |
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)
|
| | |
|
| | |
|
| |
|
|
| |
critical bug which caused packed-ref files to be written with native line endings, which made git fail to parse it. I wonder why I never noticed this before, or ignored it. Unbelievable \!
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
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.
|
