| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Previously, GitPython chokes on this while decoding. Rather than
choking, instead accept the error and replace the invalid bytes by the
� (\x80) char.
|
|
|
|
|
|
|
|
|
|
| |
This is a real commit from the microjs.com open source project, see
https://github.com/madrobby/microjs.com/commit/7e8457c17850d0991763941213dcb403d80f39f8,
which is declared to be encoded in UTF-8, but contains invalid bytes.
This makes GitPython choke on it while decoding. Rather than choking,
this should instead accept the error and replace the invalid bytes by
the � (\x80) char.
|
|
|
|
|
|
| |
Python :) !!
Related to #451
|
|
|
|
|
|
| |
Related to #451
Signed-off-by: Sebastian Thiel <byronimo@gmail.com>
|
|\
| |
| | |
Fix traceback because _seen_ops is not initialised
|
|/
|
|
| |
must call the base class __init__
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make version check much more readable, and fix it at
the same time. The previous implementation would assume
progress is supported just by looking at the patch-level
for instance.
A quick check of the git sources seems to indicate the
--progress flag exists in v1.7 of the git command-line
already.
Fixes #449
|
|
|
|
|
|
| |
That way, the base type doesn't need any adjustment.
Related to #450
|
|
|
|
| |
Related to #450
|
|
|
|
|
|
| |
Minor adjustments to PR to match current code style.
Related to #450
|
|\
| |
| | |
The progress arg to push, pull, fetch and clone is now a python calla…
|
| |\
| |/
|/| |
|
|\ \
| | |
| | | |
Use proper syntax for conditional expressions.
|
| | |
| | |
| | | |
(instead of abusing the "short-circuit" property of logical operations)
|
|\ \ \
| |/ /
|/| | |
Changing warning to debug logging, to avoid warning showing off when nothing's wrong
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
nothing's wrong
cf #444
Signed-off-by: Guyzmo <guyzmo+github@m0g.net>
|
| |
| |
| |
| | |
Related to #444
|
| | |
|
| |
| |
| |
| |
| |
| | |
That way, real-time parsing of output should finally be possible.
Related to #444
|
| |
| |
| |
| |
| |
| | |
That way, progress usage will behave as expected.
Fixes #444
|
| | |
|
| |
| |
| |
| | |
As inspired by comments in #431
|
|\ \
| | |
| | | |
import OrderedDict from git.odict rather than directly from collections, to pix Py2.6 compatibility
|
|/ /
| |
| |
| | |
pix Py2.6 compatibility
|
| |
| |
| |
| |
| |
| |
| | |
Previously, the logic was not correct. Now it should work either way,
truncating the correct list to assure both always have the same length.
Related to #442
|
| |
| |
| |
| | |
Fixes #442
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies the API and removes the parser, RemoteProgres,
from the API as RemoteProgress is an internal detail of the implementation.
progress is accepted as:
* None - drop progress messages
* callable (function etc) - call the function with the same args as update
* object - assume its RemoteProgress derived as use as before
RemoteProgress takes an optional progress_function argument.
It will call the progress function if not None otherwise call self.update
as it used to.
|
| |
|
| |
|
|
|
|
|
|
| |
Don't allow `, ` prefixes or suffixes in messages.
Fixes #438
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Opt to split lines by the new line character instead of letting
`splitlines()` do this. This helps catch the issue when there are
special characters in the line, particular the commit summary section.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Admittedly this fix is solely based on the documentation provided
for this parameter, which indicated a different intend than was
actually implemented. Also I don't believe doing this will cause
any harm.
As a special note: the call to `open(os.devnull, 'wb')` does not seem leak
the handle, apparently it is given as-is to the subprocess, which will then
close it naturally. This was tested using an interactive session via `htop`
on osx.
Fixes #437
|
|
|
|
| |
Fixes #435
|
|\
| |
| | |
Need spaces in Emacs style encoding comment
|
| |
| |
| |
| |
| | |
Although it's hard to see, PEP-0263 does have ws delimiting the 'coding' string.
This commit will fix the root cause of (at least) one bug: https://lists.fedoraproject.org/archives/list/eclipse-sig@lists.fedoraproject.org/thread/5XQ5JRHG6DPPMGRDU7TA2AO4EYS2H7AG/
|
|\ \
| | |
| | | |
Fix order of operators before executing the git command
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since Python 3.3, the hash value of an object is seeded randomly, making it
change between each call. As a consequence, the `dict` type relying on the hash
value for the order of the items upon iterating on it, and the parameters
passed to `git` being passed as `kwargs` to the `execute()` method, the order
of parameters will change randomly between calls.
For example, when you call `git.remote.pull()` in a code, two consecutives run
will generate:
1. git pull --progress -v origin master
2. git pull -v --progress origin master
Within the `transform_kwargs()` method, I'm promoting `kwargs` into an
`collections.OrderedDict` being built with `kwargs` sorted on the keys.
Then it will ensure that each subsequent calls will execute the
parameters in the same order.
|
| |
| |
| |
| | |
Fixes #430
|
| |
| |
| |
| | |
Fixes #428
|
|/
|
|
| |
Fixes #426
|
|\
| |
| | |
Update requirements doc
|
|/ |
|