| Age | Commit message (Collapse) | Author |
|---|
|
This should ensure that tests are NOT packaged into
release package by setuptools, as tests are development
only
+ fixtures after moving
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
|
|
|
|
This should ensure that tests are NOT packaged into
release package by setuptools, as tests are development
only
+ fixtures after moving
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
|
|
|
|
|
|
Solves #717
|
|
|
|
|
|
|
|
|
|
+ Some cases had restructuring of code.
|
|
That way, we do not have to figure the change type out by
examining the diff object.
It's implemented in a way that should yield more desireable results
as we keep the change-type that git is providing us with.
Fixes #493
|
|
|
|
gitpython-developers/fix-for-invalid-data-in-commits
Add test case as example of Git commit with invalid data
|
|
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.
|
|
The diff --patch parser was missing some edge case where Git would
encode non-ASCII chars in path names as octals, but these weren't
decoded properly.
\360\237\222\251.txt
Decoded via utf-8, that will return:
💩.txt
|
|
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.
|
|
This specifically covers the cases where unsafe chars occur in path
names, and git-diff -p will escape those.
From the git-diff-tree manpage:
> 3. TAB, LF, double quote and backslash characters in pathnames are
> represented as \t, \n, \" and \\, respectively. If there is need
> for such substitution then the whole pathname is put in double
> quotes.
This patch checks whether or not this has happened and will unescape
those paths accordingly.
One thing to note here is that, depending on the position in the patch
format, those paths may be prefixed with an a/ or b/. I've specifically
made sure to never interpret a path that actually starts with a/ or b/
incorrectly.
Example of that subtlety below. Here, the actual file path is
"b/normal". On the diff file that gets encoded as "b/b/normal".
diff --git a/b/normal b/b/normal
new file mode 100644
index 0000000000000000000000000000000000000000..eaf5f7510320b6a327fb308379de2f94d8859a54
--- /dev/null
+++ b/b/normal
@@ -0,0 +1 @@
+dummy content
Here, we prefer the "---" and "+++" lines' values. Note that these
paths start with a/ or b/. The only exception is the value "/dev/null",
which is handled as a special case.
Suppose now the file gets moved "b/moved", the output of that diff would
then be this:
diff --git a/b/normal b/b/moved
similarity index 100%
rename from b/normal
rename to b/moved
We prefer the "rename" lines' values in this case (the "diff" line is
always a last resort). Take note that those lines are not prefixed with
a/ or b/, but the ones in the "diff" line are (just like the ones in
"---" or "+++" 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
|
