| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 enabled getting diff patches for root commits.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
Similar to git, we now ignore options which have no value.
Previously it would not handle it consistently, and throw a parsing
error the first time the cache was built.
Afterwards, it was fully usable though.
Now we specifically check for the case of no-value options instead.
Closes #349
|
| |
|
|
|
|
|
| |
This allows us to use the main thread to parse stderr to get progress,
and resolve assertion failures hopefully once and for all.
Relates to #301
|
| |
|
|
|
| |
Test was adjusted as well to parse only a single file which simulates
stderr output.
|
| |
|
|
|
|
| |
* Previously we could fail to parse the last line within a read buffer,
which is now fixed.
* Added a test to verify our *slow* line parsing works as expected.
|
| |
|
|
|
|
|
|
|
|
|
| |
* config parser now handles quoted values correctly. This doesn't hamper
multi-line support.
* added regression test to travis to assure we will be warned if we
rewrite and break the user's .gitconfig file
* only rewrite configuration files if we actually called a mutating
method on the writer. Previously it would always rewrite it.
Fixes #285
|
| |
|
|
|
|
|
|
|
| |
Even though the test-csae only verifies this spec:
+refs/pull/*:refs/heads/pull/*
I could locally verify that it indeed handles other ones just as well:
+refs/pull/*:refs/pull/*
Fixes #243
|
| |
|
|
|
|
| |
GIT_PYTHON_TRACE would actually fail (now) if we debugged archive operations.
Related to #239
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We implement it as described in this article:
http://stackoverflow.com/questions/1557183/is-it-possible-to-include-a-file-in-your-gitconfig
Thus we handle
* cycles
* relative and absolute include paths
* write-backs in case of writable GitConfigParser instances
Fixes #201
|
| |
|
|
|
|
|
|
|
|
| |
test-file is working.
This brings us much closer to what git can do, and should at least prevent errors while reading
configuration files (which would break a lot of features, like handling of remotes since these rely
reading configuration files).
Fixes #112
|
| |
|
|
|
| |
It works as expected by me at least.
Related to #71
|
| |
|
|
| |
Related to #74
|
| |
|
|
| |
Related to #74
|
| |
|
|
| |
Fixes #74
|
| |
|
|
| |
Fixes #36
|
| |
|
|
| |
Now it's about going through PY3 issues
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://github.com/igetgames/GitPython into igetgames-feature/0.3/git-file-support
Using the previous implementation of read_gitfile, but added the previously missing test from this PR.
Conflicts:
git/repo/base.py
git/test/test_repo.py
|
| | | |
|
| |/
|
|
|
|
|
|
| |
Originals:
Pull request "GPG signature support on commit object" #124 by Tatsuki Sugiura.
https://github.com/gitpython-developers/GitPython/pull/124
commit 8065d2abdbb18e09560fc061807301b4c834d5a7
commit 62ecd6c66a84144632b045696326af503ee8cd4e
|
| |
|
|
| |
everything. Includes an updated config file which includes all the new additions
|
|
|
adjusted
|
