| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
| |
This makes sure we're not matching a \n here by accident. It's now
almost the same as the original that used \S+, except that spaces are
not eaten at the end of the string (for files that end in a space).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| | |
enrich-incremental-blame-output
|
| |
| |
| |
| | |
Since support was dropped.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This alternative API does not prevent users from using the valid treeish
"root".
|
| | |
|
| |
| |
| |
| | |
This enabled getting diff patches for root commits.
|
| |
| |
| |
| |
| | |
Returning this now to avoid having to change the function's return value
structure later on if we want to emit more information.
|
|/ |
|
|\
| |
| |
| |
| | |
Remove assertion over fetch refspec when explicitly specified
Fixes #396
|
| | |
|
|\ \
| | |
| | | |
Add incremental blame support
|
| | |
| | |
| | |
| | | |
This can be used to pass options like -C or -M.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
|/ /
| |
| |
| | |
Issue #407
|
| | |
|
|/ |
|
|
|
|
| |
Related to #396
|
|
|
|
| |
Fixes #394
|
|
|
|
|
|
| |
This tests the edge case of doing a diff against a single whitespace
filename and returns the proper change type. All other normal usage of
this diff classmethod should remain unchanged.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| | |
fix(cmd): Use buffered reads
|
| |
| |
| | |
Popen defaults to using unbuffered reads, which are extremely slow.
|
|\ \
| |/
|/| |
ENH: skip test_is_ancestor on git versions < 1.8.0 not supporting git merge-base --is-ancestor
|
| |
| |
| |
| | |
merge-base --is-ancestor
|
| |
| |
| |
| | |
if used as context managers, the parsers will automatically release their file locks.
|
| |
| |
| |
| | |
Related to #383
|
| |
| |
| |
| | |
Thanks travis, once again !
|
|/
|
|
| |
Fixes #383
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We keep stdout closed, which seems to have the side-effect of
stdout being connected to your TTY, in case you run a terminal.
However, this shold also prevent deadlocks, as only stderr is used.
The alternative would have been to try to fetch lines concurrently,
and we have been there.
For clone(), `communicate()` is used, and with some luck this will
just do the right thing. Even though last time I checked, it
didn't ... ? Lets see.
Stab at #72
|
| |
|
|
|
|
|
|
| |
Previously, it could have happened that pipes ran full, deadlocking the operation
Related to #72
|
| |
|
|
|
|
|
| |
signal.SIGKILL is not available on Windows so use signal.SIGTERM as a backup
when SIGKILL is not available.
|
|
|
|
|
|
| |
For more information, see CHANGES.rst
Fixes #369
|
|
|
|
|
|
|
|
|
|
| |
The problem is that a per-tree modification API cannot work properly, as the sorting is based
on full paths of all entries within the repository. This feat can only be achieved by the index,
which to my knowledge already does it correctly.
The only fix is to remove the misleading API entirely, which will happen in the next commit.
Related to #369
|
|
|
|
| |
[skip ci]
|
|
|
|
|
|
|
|
|
| |
Previously it was possible to generate trees which didn't
appear legit to git as gitpython's sorting was a simple alpha-numeric
sort. Git uses one that minimizes literal string comparisons though,
and thus behaves slightly differently sometimes.
Fixes #369
|
| |
|
|
|
|
| |
Closes #330
|
|
|
|
| |
Related to #362
|