Skip to content

README.md

Latest commit

 

History

History
291 lines (201 loc) · 12.3 KB

README.md

File metadata and controls

291 lines (201 loc) · 12.3 KB
Raw

Python package Documentation Status Packaging status

GixPython: Gitoxide for GitPython

GixPython provides the Python bindings for Gitoxide, an implementation of Git in Rust. GitPython's experimental Gix backend uses these bindings to execute supported operations through Gitoxide while exposing GitPython's high-level repository, commit, tree and index interfaces.

Supported object reads, tree traversal, reference/index queries and commit history can run without launching Git subprocesses. GitPython also retains and reuses a Gix repository handle across operations, reducing repeated initialization work. These changes reduce subprocess overhead, particularly for repeated repository queries; the backend benchmarks measure results and CLI launch counts for both backends.

Activate the Gix backend

This backend is currently unreleased. From this source checkout, install the optional gix extra in a virtual environment:

python -m pip install ".[gix]"

The extra installs GixPython 0.3.0 from PyPI; its Python import name is gix. Set GIT_PYTHON_BACKEND=gix before importing GitPython, either in your environment or in Python:

import os

os.environ["GIT_PYTHON_BACKEND"] = "gix"
from git import Repo

with Repo(".") as repo:
    print(repo.head.commit.hexsha)

With GIT_PYTHON_BACKEND unset, GitPython automatically selects Gix when gix can be imported, otherwise CLI. Set it to cli to force Git subprocesses instead. Explicit gix selection fails if GixPython cannot be imported.

Prerequisites and coverage

  • CPython 3.11 or newer for GixPython. GitPython itself still supports Python 3.8 or newer; on Python 3.8–3.10 the extra omits GixPython and uses CLI.
  • Git 2.52 or newer, available in PATH or selected with GIT_PYTHON_GIT_EXECUTABLE, remains required for CLI fallbacks.
  • GixPython 0.3.0 publishes macOS wheels. On Linux and Windows, installation builds its released source distribution and requires Rust 1.89 or newer and a system linker. Default hashing, compression and HTTPS dependencies use pure Rust and do not require a C/C++ compiler.

Unsupported operations and options retain the Git CLI path, including clone, fetch and push. Direct repo.git.<command>() calls also retain command-line behavior. Coverage and compatibility gaps are documented in the backend ledger and installation guide; the downstream audit starts with known API incompatibilities.

GitPython

GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.

It provides abstractions of git objects for easy access of repository data often backed by calling the git command-line program.

DEVELOPMENT STATUS

This project is in maintenance mode, which means that

  • …there will be no feature development, unless these are contributed
  • …there will be no bug fixes, unless they are relevant to the safety of users, or contributed
  • …issues will be responded to with waiting times of up to a month

The project is open to contributions of all kinds, as well as new maintainers.

REQUIREMENTS

GitPython needs the git executable to be installed on the system and available in your PATH for repository operations. If it is not in your PATH, you can help GitPython find it by setting the GIT_PYTHON_GIT_EXECUTABLE=<path/to/git> environment variable.

  • Git (2.52 or newer)
  • Python >= 3.8

The list of dependencies are listed in ./requirements.txt and ./test-requirements.txt. The installer takes care of installing them for you.

INSTALL

GitPython and its required package dependencies can be installed in any of the following ways, all of which should typically be done in a virtual environment.

From PyPI

To obtain and install a copy from PyPI, run:

pip install GitPython

(A distribution package can also be downloaded for manual installation at the PyPI page.)

From downloaded source code

If you have downloaded the source code, run this from inside the unpacked GitPython directory:

pip install .

By cloning the source code repository

To clone the the GitHub repository from source to work on the code, you can do it like so:

git clone https://github.com/gitpython-developers/GitPython
cd GitPython
./init-tests-after-clone.sh

On Windows, ./init-tests-after-clone.sh can be run in a Git Bash shell.

If you are cloning your own fork, then replace the above git clone command with one that gives the URL of your fork. Or use this gh command (assuming you have gh and your fork is called GitPython):

gh repo clone GitPython

Having cloned the repo, create and activate your virtual environment.

Then make an editable install:

pip install -e ".[test]"

In the less common case that you do not want to install test dependencies, pip install -e . can be used instead.

With editable dependencies (not preferred, and rarely needed)

GitPython, gitdb, and smmap live in this repository as independently packaged projects. To work on all three at once, install each one editably in the same virtual environment:

pip install -e smmap -e gitdb -e ".[test]"

You can use pip list to check which packages are installed editably and which are installed normally.

To reiterate, this approach should only rarely be used. For most development it is preferable to allow the gitdb and smmap dependencices to be retrieved automatically from PyPI in their latest stable packaged versions.

Limitations

Leakage of System Resources

GitPython is not suited for long-running processes (like daemons) as it tends to leak system resources. It was written in a time where destructors (as implemented in the __del__ method) still ran deterministically.

In case you still want to use it in such a context, you will want to search the codebase for __del__ implementations and call these yourself when you see fit.

Another way assure proper cleanup of resources is to factor out GitPython into a separate process which can be dropped periodically.

Windows support

See Issue #525.

RUNNING TESTS

Important: Right after cloning this repository, please be sure to have executed the ./init-tests-after-clone.sh script in the repository root. Otherwise you will encounter test failures.

Install test dependencies

Ensure testing libraries are installed. This is taken care of already if you installed with:

pip install -e ".[test]"

If you had installed with a command like pip install -e . instead, you can still run the above command to add the testing dependencies.

Test commands

To test, run:

pytest

To lint, and apply some linting fixes as well as automatic code formatting, run:

pre-commit run --all-files

This includes the linting and autoformatting done by Ruff, as well as some other checks.

To typecheck, run:

mypy

CI (and tox)

Style and formatting checks, and running tests on all the different supported Python versions, will be performed:

  • Upon submitting a pull request.
  • On each push, if you have a fork with GitHub Actions enabled.
  • Locally, if you run tox (this skips any Python versions you don't have installed).

Configuration files

Specific tools are all configured in the ./pyproject.toml file:

  • pytest (test runner)
  • coverage.py (code coverage)
  • ruff (linter and formatter)
  • mypy (type checker)

Orchestration tools:

Contributions

Please have a look at the contributions file.

INFRASTRUCTURE

  • User Documentation
  • Questions and Answers
  • Please post on Stack Overflow and use the gitpython tag
  • Issue Tracker
    • Post reproducible bugs and feature requests as a new issue when you do not have a fix or need discussion before implementation. If you have a fix or improvement, open a pull request directly and describe the problem there; you do not need to create an issue first. Please be sure to provide the following information when reporting bugs in an issue or PR:
      • GitPython version (e.g. import git; git.__version__)
      • Python version (e.g. python --version)
      • The encountered stack-trace, if applicable
      • Enough information to allow reproducing the issue

How to make a new release

  1. Update/verify the version in the VERSION file.
  2. Update/verify that the doc/source/changes.rst changelog file was updated. It should include a link to the forthcoming release page: https://github.com/gitpython-developers/GitPython/releases/tag/<version>
  3. Commit everything.
  4. Run git tag -s <version> to tag the version in Git.
  5. Optionally create and activate a virtual environment. (Then the next step can install build and twine.)
  6. Run make release.
  7. Go to GitHub Releases and publish a new one with the recently pushed tag. Generate the changelog.

Projects using GitPython

LICENSE

3-Clause BSD License, also known as the New BSD License. See the LICENSE file.

One file exclusively used for fuzz testing is subject to a separate license, detailed here. This file is not included in the wheel or sdist packages published by the maintainers of GitPython.