| Age | Commit message (Collapse) | Author |
|---|
|
The a_path and b_path cannot reliably be read from the first diff line
as it's ambiguous. From the git-diff manpage:
> The a/ and b/ filenames are the same unless rename/copy is involved.
> Especially, **even for a creation or a deletion**, /dev/null is not
> used in place of the a/ or b/ filenames.
This patch changes the a_path and b_path detection to read it from the
more reliable locations further down the diff headers. Two use cases
are fixed by this:
- As the man page snippet above states, for new/deleted files the a
or b path will now be properly None.
- File names with spaces in it are now properly parsed.
Working on this patch, I realized the --- and +++ lines really belong to
the diff header, not the diff contents. This means that when parsing
the patch format, the --- and +++ will now be swallowed, and not end up
anymore as part of the diff contents. The diff contents now always
start with an @@ line.
This may be a breaking change for some users that rely on this
behaviour. However, those users could now access that information more
reliably via the normal Diff properties a_path and b_path now.
|
|
|
|
|
|
This alternative API does not prevent users from using the valid treeish
"root".
|
|
This enabled getting diff patches for root commits.
|
|
This protects against `.split(None)` which uses consecutive whitespace
as a separator to overlook paths where a single space is the filename.
For example, in this diff line:
line = ':100644 000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
0000000000000000000000000000000000000000 D '
The deleted file is a file named ' ' (just one space). It's entirely
possible to commit this, remove, and to produce the following output
from `git diff`:
git diff --name-status <SHA1> <SHA2>
D
M path/to/another/file.py
...
This would cause the initial `.split(None, 5)` to fail as it will count
all consecutive whitespace as a separator, disregarding the ' ' (single
space) filename.
|
|
If the file was not present, the mode seen in a diff can be legally '0',
which previously caused an assertion to fail for no good reason.
Now the assertion tests for None instead.
Closes #323
|
|
If a file in a commit contains no changes (for example, if only the
file mode is changed) there will be no blob attached. This is
usually where the filename is stored, so without it, the calling
context can not tell what file was changed. Instead, always
store a_path and b_path on the Diff object so that information
is available.
|
|
That way they are protected from regression.
Fixes #239
|
|
Additionally, unicode handling was improved to the point where we deal
with all diff(create_path=True) data as binary.
Therefore we don't claim to know all encodings of all textfiles in the world,
even though we still assume that everything git throws at us is utf-8 encoded.
Fixes #113
|
|
future
There is still some work todo in terms of how we handle the encoding
|
|
Related to #74
|
|
Fixes #36
|
|
Helps fixing #35
Also, the production status was changed to 'stable', which should
have been done much earlier.
|
|
|
|
|
|
More to come, especially when it's about strings
|
|
There is more work to do though, as many imports are still incorrect.
Also, there are still print statements
|
|
Commandline was
autopep8 -j 8 --max-line-length 120 --in-place --recursive --exclude "*gitdb*,*async*" git/
|
|
W291 trailing whitespace
|
|
E201 whitespace after '('
E202 whitespace before ')'
E203 whitespace before ':'
E225 missing whitespace around operator
E226 missing whitespace around arithmetic operator
E227 missing whitespace around bitwise or shift operator
E228 missing whitespace around modulo operator
E231 missing whitespace after ','
E241 multiple spaces after ','
E251 unexpected spaces around keyword / parameter equals
|
|
E301 expected 1 blank line, found 0
E302 expected 2 blank lines, found 1
E303 too many blank lines (n)
|
|
W191 indentation contains tabs
E221 multiple spaces before operator
E222 multiple spaces after operator
E225 missing whitespace around operator
E271 multiple spaces after keyword
W292 no newline at end of file
W293 blank line contains whitespace
W391 blank line at end of file
|
|
See https://github.com/gitpython-developers/GitPython/issues/172 for
more information
|
|
probably a good idea to go a little more pep8 (and fix sins of my youth ;) )
|
|
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.
|
|
specific subprocess bug occurs.
|
|
adjusted
|
