| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
+ PY3 means "PY3 or later" (TODO: fix also for *gitdb* project).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the following fields on Diff instances were assumed to be
passed in as unicode strings:
- `a_path`
- `b_path`
- `rename_from`
- `rename_to`
However, since Git natively records paths as bytes, these may
potentially not have a valid unicode representation.
This patch changes the Diff instance to instead take the following
equivalent fields that should be raw bytes instead:
- `a_rawpath`
- `b_rawpath`
- `raw_rename_from`
- `raw_rename_to`
NOTE ON BACKWARD COMPATIBILITY:
The original `a_path`, `b_path`, etc. fields are still available as
properties (rather than slots). These properties now dynamically decode
the raw bytes into a unicode string (performing the potentially
destructive operation of replacing invalid unicode chars by "�"'s).
This means that all code using Diffs should remain backward compatible.
The only exception is when people would manually construct Diff
instances by calling the constructor directly, in which case they should
now pass in bytes rather than unicode strings.
See also the discussion on
https://github.com/gitpython-developers/GitPython/pull/467
|
| |
|
|
|
|
|
| |
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/
|
|
|
|
| |
Since support was dropped.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a sibling method to Repo's blame method:
Repo.blame_incremental(rev, path, **kwargs)
This can alternatively be called using:
Repo.blame(rev, path, incremental=True)
The main difference is that blame incremental is a bit more efficient
and does not return the full file's contents, just the commits and the
line number ranges. The parser is a bit more straight-forward and
faster since the incremental output format is defined a little stricter.
|
|
|
|
| |
See #177
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Kind of tackling the tasks step by step, picking low-hanging fruit first,
or the ones that everyone depends on
|
|
|
|
| |
Now it's about going through PY3 issues
|
|
|
|
|
|
| |
However, StringIO really is ByteIO in most cases, and py2.7 should
run but doesn't.
This should be made work first.
|
|
More to come, especially when it's about strings
|