| 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.
|
|\
| |
| |
| | |
enrich-incremental-blame-output
|
| | |
|
| |
| |
| |
| | |
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.
|
|\
| |
| | |
Add incremental blame support
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| | |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
Previously, it could have happened that pipes ran full, deadlocking the operation
Related to #72
|
| |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As GitPython is in maintenance mode, there will be no new features.
However, I believe it's good idea to explicitly state we do not support
certain things if this is the case.
Therefore, when worktrees are encountered, we will throw an specific
exception to indicate that.
The current implementation is hacky to speed up development,
and increases the risk of failing due to false-positive worktree
directories.
Related to #344
|
|
|
|
|
|
| |
This should fix resource leaking issues once and for all.
Related #304
|
|\
| |
| | |
fix(cmd): make short options with arguments become two separate argum…
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I really never want to touch python again, and never deal with
py2/3 unicode handling anymore.
By now, it seems pretty much anything is better.
Is python to be blamed for it entirely ?
Probably not, but there are better alternatives.
Nim ? Rust ? Ruby ?
Totally
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously timezones which were not divisable by 3600s would be
parsed correctly, but would serialize into a full hour, rounded up.
Now floating point computation is used which fixes the issue.
Related to #336
|
| |
| |
| |
| |
| |
| |
| | |
Now we select the submodule by name, not by index. The latter is not
deterministic.
Closes #335
|
| |
| |
| |
| |
| |
| |
| |
| | |
It's somewhat more complex to add new commits in submodules to the
parent repository. The new test shows how to do that in a 'GitPythonic'
way.
Related to #335
|
|/
|
|
|
|
|
|
|
| |
This issue only surfaced in python 2, in case paths containing unicode
characters were not actual unicode objects.
In python 3, this was never the issue.
Closes #331
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Wrap `git merge-base --is-ancestor` into its own function because it acts
as a boolean check unlike base `git merge-base call`
|
|
|
|
|
|
|
|
|
|
|
|
| |
* untracked_files could, if there were spaces in the path returned,
re-rencode the previously decoded unicode string thanks to a
`decode("string_escape")` call. Now re-encode into utf-8 afterwards
- added test to assure this works indeed
* IndexFile.add() didn't handle unicode correctly and would write
broken index files. The solution was to compute the path length after
encoding it into utf-8 bytes, not before ... .
Closes #320
|
| |
|
|
|
|
|
|
|
|
|
| |
revA..revB → revA...revB (three instead of two dots) [base.py, line
467](https://github.com/gitpython-developers/GitPython/blob/master/git/repo/base.py#L467)
rorepo is a ~~a~~ Repo instance [test_docs.py, line
21](https://github.com/gitpython-developers/GitPython/blob/master/git/test/test_docs.py#L21)
closes #314
|
|
|
|
| |
Seems like OSX is somewhat special here ... .
|
|
|
|
|
|
| |
Fixed additional test which seems to have different outcomes depending
on the interpreter. This just makes it work withouth attempting
to find the root cause of the issue.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
It shows that the previous implementation was never really working on
linux, and thus failed on travis as well for good reason.
Closes #303
|
|
|
|
|
|
|
|
|
|
| |
When expanding directories, check if it is a symlink and don't expand
them at all.
Previously, we followed symlinks and expanded their contents, which
could lead to weird index files.
Fixes #302
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out we can't deal do fetches if no refspec is set as git
will change the format of the fetch return values, providing less
information than usual.
A test was added to show that such a case will fail, and an assertion
will assure we don't attempt to fetch/pull if there is no refspec
for 'fetch'.
Closes #296
|
|
|
|
|
|
|
|
|
| |
In that case, the handler for processing stdout and stderr of the git
process is offloaded to threads. These currently don't return
any exception they raise.
We could easily fix this using an approach as shown
[here](http://goo.gl/hnVax6).
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
| |
add a GIT_PYTHON_TEST_GIT_DAEMON_PORT to set a port other than 9418,
for example for when you already have a daemon running on that port.
|
|
|
|
|
|
|
|
|
|
|
|
| |
No reason to expose a daemon to all interfaces when it is only used for
tests, which connect to localhost anyway.
I'd love to use localhost here instead, but the git-daemon man page points out:
If IPv6 is not supported, then --listen=hostname is also not
supported and --listen must be given an IPv4 address.
I don't know of a way to check if git has ipv6 support, but 127.0.0.1
should be around for the foreseeable future
|