| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GitPython parses the output of `git diff --numstat` to get the
files changed in a commit.
This breaks when a commit contains a file rename, because the output
of `git diff` is different than expected.
This is the output of a normal commit:
$ git diff --numstat 8f41a390bf9a^ 8f41a390bf9a
30 5 test/test_repo.py
And this a commit containing a rename:
$ git diff --numstat 185d847ec764^ 185d847ec764
3 1 .github/workflows/{test_pytest.yml => Future.yml}
This can be triggered by this code:
for commit in repo.iter_commits():
print(commit.hexsha)
for file in commit.stats.files:
print(file)
Which will print for the normal commit:
8f41a390bf9a54db6f85032bc56b453307b95451
'test/test_repo.py'
And when there is a rename:
185d847ec7647fd2642a82d9205fb3d07ea71715
'.github/workflows/{test_pytest.yml => Future.yml}'
Additionally, when a path member is removed, the file list become
a list of strings, breaking even more the caller. This is in the
Linux kernel tree:
$ git diff --numstat db401875f438^ db401875f438
1 1 tools/testing/selftests/drivers/net/mlxsw/{spectrum-2 => }/devlink_trap_tunnel_ipip6.sh
and GitPython parses it as:
db401875f438168c5804b295b93a28c7730bb57a
('tools/testing/selftests/drivers/net/mlxsw/{spectrum-2 => '
'}/devlink_trap_tunnel_ipip6.sh')
Fix this by pasing the --no-renames option to `git diff` which ignores
renames and print the same output as if the file was deleted from the
old path and created in the new one:
$ git diff --numstat --no-renames 185d847ec764^ 185d847ec764
57 0 .github/workflows/Future.yml
0 55 .github/workflows/test_pytest.yml
|
| |\
| |
| | |
Fix some resource leaks by open file handles
|
| |/ |
|
| |\
| |
| | |
use tempfile.TemporaryDirectory & fix clone_from_unsafe_protocol tests
|
| | | |
|
| | | |
|
| |\ \
| |/
|/| |
fix/add allow_unsafe_* params in docstrings + fix typo
|
| |/ |
|
| |
|
|
|
|
|
|
| |
Use `command -v` to locate the git executable instead of `which`.
The former is guaranteed to always be available according to POSIX,
while which(1) is a redundant third-party tool that is slowly being
phased out from Linux distributions. In particular, Gentoo no longer
installs it by default.
|
| |
|
|
|
|
|
|
| |
These errors are mostly fixed by either adding blank lines or single
spaces for Sphinx documentation key words.
The commit solely includes documentation changes, no functional
changes.
|
| | |
|
| |\
| |
| | |
Block insecure options and protocols by default
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Since the URL is passed directly to git clone, and the remote-ext helper
will happily execute shell commands, so by default disallow URLs that
contain a "::" unless a new unsafe_protocols kwarg is passed.
(CVE-2022-24439)
Fixes #1515
|
| | |
| |
| |
| | |
pycharm yells at me without this
|
| |/ |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Taken from https://github.com/gitpython-developers/GitPython/pull/1516/
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add `--` in some commands that receive user input
and if interpreted as options could lead to remote
code execution (RCE).
There may be more commands that could benefit from `--`
so the input is never interpreted as an option,
but most of those aren't dangerous.
Fixed commands:
- push
- pull
- fetch
- clone/clone_from and friends
- archive (not sure if this one can be exploited, but it doesn't hurt
adding `--` :))
For anyone using GitPython and exposing any of the GitPython methods to users,
make sure to always validate the input (like if starts with `--`).
And for anyone allowing users to pass arbitrary options, be aware
that some options may lead fo RCE, like `--exc`, `--upload-pack`,
`--receive-pack`, `--config` (https://github.com/gitpython-developers/GitPython/pull/1516).
Ref https://github.com/gitpython-developers/GitPython/issues/1517
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [cygwin/cygwin-install-action](https://github.com/cygwin/cygwin-install-action) from 2 to 3.
- [Release notes](https://github.com/cygwin/cygwin-install-action/releases)
- [Commits](https://github.com/cygwin/cygwin-install-action/compare/v2...v3)
---
updated-dependencies:
- dependency-name: cygwin/cygwin-install-action
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
| | |
|
| |\
| |
| | |
Add datetime.datetime type to commit_date and author_date
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
| |
It would fail to perform the replacement, but unfortunately wouldn't
stop the release process.
The latter could be done, but isn't implemented either as it's hard
to test given everything is runtime.
|
| |
|
|
|
| |
The new key isn't signed with the old key so not accepted downstream,
and that's it as the old key literally broke and there is no backup.
|
| | |
|
| | |
|
| |\
| |
| | |
Ignore empty info in diff line
|
| |/ |
|
| |\
| |
| | |
Fix bug where colons in paths raise a `ValueError` on `diff()` calls.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces a potential fix for #1490 and #1483, in which an
`invalid literal for int() with base 10: 'n'` exception was raised
within a diff operation. Within `_handle_diff_line()`, we split the
output of `git diff-tree` on colons (`:` characters), under the
assumption that there are no colons within the paths of the files being
diffed. On POSIX systems this is not a valid assumption. The fix is to
split on `\x00:`, since a null character always precedes the colons we
actually need to split on.
A test already existed for this case (`test_diff_file_with_colon()`),
but it was marked as skipped.
* Split on `\x00:` instead of `:` in `_handle_diff_line()`.
* Unskip `test_diff_file_with_colon()`.
|
| |\
| |
| | |
feat(blame): Support custom `rev_opts` for blame
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `git blame` CLI offers a repeated `-C` option that can be used to detect
lines that move within/between files. While a slower operation, it yields more
accurate authorship reports.
https://git-scm.com/docs/git-blame#Documentation/git-blame.txt--Cltnumgt
While GitPython does enable passing custom kwargs to the command line `git`
invocation, the fact that kwargs is a dictionary (i.e. no duplicate keys) means
that there was no way to request the `-C` option in `git blame` more than once.
This commit adds an optional `rev_opts` parameter to the `blame` method which
accepts a list of strings to propagate to the CLI invocation of `git blame`. By
using a `List[str]` for `rev_opts`, users of GitPython can pass now the `-C`
option multiple times to get more detailed authorship reports from `git blame`.
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
_from_string classmethod.
|
| | |
| |
| |
| | |
regex.
|
| |/
|
|
| |
message for designated co-authors, include a simple test.
|
| |\
| |
| | |
Improve docs
|
| | |\ |
|
